innodb_lru_scan_depth是5.6新增加的参数，根据官方文档描述，它会影响page cleaner线程每次刷脏页的数量，这是一个每1秒 loop一次的线程。
在Innodb内部，这个参数对应变量为srv_LRU_scan_depth
grep了一把，有几个地方会涉及到这个参数
1.buf/buf0lru.cc
buf_LRU_free_from_unzip_LRU_list
在扫描bp->unzip_LRU时保证扫描深度不超过srv_LRU_scan_depth，以从其中释放一个压缩块的非压缩页。
在5.5中，则有一个计算公式
distance = 100 + (n_iterations
* UT_LIST_GET_LEN(buf_pool->unzip_LRU)) / 5;
n_iterations越大，表示扫描了多次（或者说一次请求空闲块进入这个函数的次数），值不超过5.
buf_LRU_free_from_common_LRU_list
与上述情况类似，但扫描的是bp->LRU。
这两个函数主要用于从LRU获取空闲块（例如free list已空），均有一个参数scan_all，当为true时，表示扫描全部LRU链表，这时候srv_LRU_scan_depth就不起作用了。
我们知道获取空闲块的入口函数是buf_LRU_get_free_block，之前也做过5.5关于这个函数的分析（见http://mysqllover.com/?p=387）
在5.6中，如果free list为空，则
>如果有flush在发生，等待完成并重试
>如果buf_pool->try_LRU_scan为true，则扫描srv_LRU_scan_depth深度的LRU，成功则返回空闲快
>如果上一步失败，iteration=1，扫描整个LRU链表
>如果上一步失败，iteration>1，依然扫描整个LRU链表，但sleep 100000us
2.buf/buf0flu.cc:
这里主要是page cleaner线程调用
buf_flush_page_cleaner_thread //page cleaner线程入口
|—>buf_flush_LRU_tail
|–>扫描LRU，调用srv_LRU_scan_depth/PAGE_CLEANER_LRU_BATCH_CHUNK_SIZE（）次buf_flush_LRU函数，每次尝试去处理100个block.划分成chunk的目的是防止用户线程在请求空闲块时等待时间太长
buf_flush_LRU-> buf_do_LRU_batch
buf_free_from_unzip_LRU_list_batch
从buf_pool->unzip_LRU上把非压缩frame移到bp->free上，如果bp->free的长度大于等于srv_LRU_scan_depth会跳出
buf_flush_LRU_list_batch
和上面的类似，但是从bp->LRU上扫描
可见srv_LRU_scan_depth会控制从LRU上清理block并将其放到free list上的扫描深度，不光影响page cleaner线程，也会影响用户线程；
从其作用可以看出，当系统的IO比较空闲的时候，可以适当将这个参数设大，当IO吃紧时，需要适当减小
related bug:
http://bugs.mysql.com/bug.php?id=68481
http://bugs.mysql.com/bug.php?id=68497
related blog:
http://mysqlha.blogspot.com/2013/02/mysql-56-io-bound-update-only-workloads.html
