在刚刚放出来的MySQL5.6.17版本中，最引人注意的功能当属于能够在线的进行opimitze table操作，这可以帮助减小表的大小而无需阻塞并发负载，另外以下几类操作也开始支持online ddl:
-
ALTER TABLE ... ENGINE=INNODB(when run on anInnoDBtable)
上述操作将触发表的rebuild，代码的改动量非常小
修改见 【Rev:5820】
这几个选项从sql_mode中移除了：ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE；而是在严格模式中默认开启(【Rev:5829】)
ALTER IGNORE TABLE 也被弃用（目前只是打印warning，未来版本可能移除掉），根据描述，该类操作可能导致对unique key的ddl操作及外键操作以及复制问题 （搞不定一些问题就把他干掉。。。。呵呵）(修改见【Rev:5745】)
其他一些比较有意思的bugfix
【Rev:5800】
开始支持分区表的flush table for export，但依然不支持分区表的ALTER TABLE DISACARD/IMPORT TABLESPACE （不知道会否进一步开发）
【Rev:5846】
修复一个压缩表性能退化的bug（bug#71436）
调整了zip_mutex的顺序（buf_page_get_gen），当读入一个压缩页，实际上在递增计数器buf_pool->n_pend_unzip后，就可以直接释放buf_pool->zip_mutex
【Rev:5753】
purge协调线程和innodb monitor线程在shutdown时可能产生race condition（bug#70430）
因为purge线程退出时，还有可能进入到函数lock_print_info_summary中 ， 之前的ut_error被移除掉了
另外一个和shutdown相关的bug， shutdown可能hang住（【Rev:5752】），也和purge线程的状态相关；
【Rev:5758】
在打开innodb_stats_persistent时，CREATE TABLE时需要向mysql.innodb_index_stats表中插入多条记录，每次插入都会commit一次，现在改成只commit一次（buf#70063）
见函数dict_stats_save_index_stat/dict_stats_save
【Rev:5764】
在函数lock_rec_has_to_wait_in_queue中触发断言导致crash
row_vers_impl_x_locked_low用于检查一个二级索引记录是否被一个活跃的事务插入/删除；我们知道在innodb的二级索引页中，只记录了最大修改事务id，通过回溯聚集索引记录的undo旧版本，构建聚集索引记录并判断记录中的事务id是否活跃；bug的原因是在函数row_vers_impl_x_locked_low中错误的标识一个事务在二级索引上持有隐式锁，而该二级索引记录可能已经被标记删除并且没有与之关联的聚集索引记录；修复的方法是再判断一次二级索引记录是否被delete mark了（因为永远不会去试图插入一条被delete-mark的记录），如果是的话，则返回0 （表示修改已经commit）
另外LOCK_CONV_BY_OTHER（隐式锁转换标记）在该版本中被移除掉了；
【Rev:4587】
由于不正确的处理外部存储页的change buffer merge，可能触发断言失败（挂在函数row_upd_clust_rec_by_insert中的断言检查）：
InnoDB: Failing assertion: rec_get_deleted_flag(rec, page_is_comp(page))
函数row_upd_changes_ord_field_binary_func用于决定是row_upd_clust_rec_by_insert （delete + insert）还是调用row_upd_clust_rec(in-place更新)的方式来更新聚集索引记录，在该函数中并没有使用到字符集，只是简单的根据二进制比较修改前后的记录顺序；而在函数row_upd_clust_rec_by_insert中则考虑到了字符集(使用cmp_dtuple_rec_with_match比较)， 这意味着刚刚被标记删除的记录位置，随后即被插入了新的记录，当有其他外部存储列时，可能被错误的处理；例如在拉丁字符集中,’A’和’a’是相同的，因此会被插入到同一条记录位置；而随后检查到老记录的位置并没有被delete mark，因此触发断言失败
在Rev中提供了test case，感兴趣的同学可以在5.6.17之前的版本中尝试下，立刻挂的节奏….
对于innodb表，减小auto_increment_increment没有生效（bug#65225）
开启并行复制导致内存一直上涨不释放的问题， 原因是分发线程使用的memroot一直到stop slave才被释放，而每次读事务都可能递增该内存使用量(bug#71197)
【Rev:5838】
在之前的版本中，ordered_commit函数中，事务先被写到Binlog，然后通知dump线程，再进行fsync操作(sync_binlog= 1)，如果这中间crash，可能导致备库比主库的binlog更多，sync_binlog=1的强持久看起来就没有意义了(bug#70669)
新的逻辑保证在sync_binlog=1时不释放LOCK_log锁，直到binlog被sync到磁盘中；
【Rev:5739】
当备库上表的列比主库多一个自增列时，ROW模式下复制时，并没有为该列递增值(bug#69680)
【Rev:5782】
禁止复制对performance scheama表的DML操作
【Rev:5788】
切换semisync 打开/关闭状态导致的crash （bug#66411）
问题在于事务在commitTrx函数中，会先无锁检查semisync是否打开，然后在加锁检查，如果在加锁之前semisync被disable，active_tranxs_会被清空，加锁后当前线程判定semisync打开后，又会去判断当前事务的位点是否被注册(active_tranxs_->is_tranx_end_pos)，从而触发断言失败
事实上这个fix在5.6.16版本上已经是多余的了，因为在检查active_tranxs_->is_tranx_end_pos之前已经预先判断了是否打开了semisync：
assert(!getMasterEnabled() ||
!active_tranxs_->is_tranx_end_pos(trx_wait_binlog_name,
trx_wait_binlog_pos));
【Rev:5773】
当有多个dump线程时，可能导致semisync的plugin lock冲突非常明显，进而引发性能下降(bug#70218)
新的逻辑里将semi dump线程的状态返回到server层，只有在开启了semisync的dump线程才去调用HOOK
【Rev:5779】
The optimizer could push down a condition when the index did not have the key part present in the condition.
【Rev:5761】
SELECT DISTINCT …GROUP BY可能返回错误的结果集(bug#70657)
在子查询里进行ALL()+GROUP BY的聚合操作可能返回错误的结果集（bug#71244）
