[MySQL 5.6] Percona Server 5.6.16的主要改进

<a href="http://www.percona.com/doc/percona-server/5.6/management/backup_locks.html#backup-locks">backup locks</a>

<code>lock tables for backup //使用一种新的mdl锁来阻塞对非事务表的dml以及对所有表的ddl，但不阻塞select查询</code>

<code>lock binlog for backup //阻止对binlog位点的更新，也就是说对于dml/ddl操作会一直进行直到需要写入binlog的阶段被阻塞</code>

<code>unlock binlog  // 解除lock binlog for backup</code>

另外facebook很早就写了个补丁来绕过ftwrl，具体做法就是增加了新的语法，能够开启一个read view的同时返回当前与read view一致的binlog位点，但只适用于所有的表都是innodb引擎；

<a href="http://www.percona.com/doc/percona-server/5.6/performance/xtradb_performance_improvements_for_io-bound_highly-concurrent_workloads.html#lru-manager-thread">lru manager thread</a>

使用新的独立后台线程来刷buffer pool的lru链表，将这部分工作负担从page cleaner线程剥离。实际上就是直接转移刷lru的代码到独立线程了，

实际从之前percona的版本来看，都是在不断的强化后台线程，让用户线程少参与到刷脏/checkpoint这类耗时操作中

page cleaner线程对server acitve的判断

percona做的修改是，只有1秒钟内innodb没有任何active，才认为实例处于inactive状态，会去做100% io capacticy的刷脏操作（furious flush）

修复5.6.16的一个性能退化bug

当开启change buffer时，innodb会频繁的创建dummy table(一种用于线程私有的简单的索引结构)，这种dummy index事实上无需使用states_latch，因为他是线程私有的；但oralce mysql没有做区分，而在创建rw lock时，会加全局锁rw_lock_list_mutex来维护全局读写锁链表rw_lock_list，这在cpu bound场景下，观察到如下的stall：