[MySQL5.6] MySQL 5.6.17新特性：online optimize table （以及其他主要bugfix）

在剛剛放出來的mysql5.6.17版本中，最引人注意的功能當屬于能夠線上的進行opimitze table操作，這可以幫助減小表的大小而無需阻塞并發負載，另外以下幾類操作也開始支援online ddl:

<a href="http://dev.mysql.com/doc/refman/5.6/en/optimize-table.html" target="_top"><code>optimize table</code></a>

<a href="http://dev.mysql.com/doc/refman/5.6/en/alter-table.html" target="_top"><code>alter table ... force</code></a>

上述操作将觸發表的rebuild，代碼的改動量非常小

其他一些比較有意思的bugfix

開始支援分區表的flush table for export，但依然不支援分區表的alter table disacard/import tablespace （不知道會否進一步開發）

修複一個壓縮表性能退化的bug（bug#71436）

調整了zip_mutex的順序（buf_page_get_gen），當讀入一個壓縮頁，實際上在遞增計數器buf_pool-&gt;n_pend_unzip後，就可以直接釋放buf_pool-&gt;zip_mutex

purge協調線程和innodb monitor線程在shutdown時可能産生race condition（bug#70430）

因為purge線程退出時，還有可能進入到函數lock_print_info_summary中 ， 之前的ut_error被移除掉了

在打開innodb_stats_persistent時，create table時需要向mysql.innodb_index_stats表中插入多條記錄，每次插入都會commit一次，現在改成隻commit一次（buf#70063）

見函數dict_stats_save_index_stat/dict_stats_save

在函數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（隐式鎖轉換标記）在該版本中被移除掉了；

由于不正确的處理外部存儲頁的change buffer merge，可能觸發斷言失敗（挂在函數row_upd_clust_rec_by_insert中的斷言檢查）：

函數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)

在之前的版本中，ordered_commit函數中，事務先被寫到binlog，然後通知dump線程，再進行fsync操作(sync_binlog= 1)，如果這中間crash，可能導緻備庫比主庫的binlog更多，sync_binlog=1的強持久看起來就沒有意義了(bug#70669)

新的邏輯保證在sync_binlog=1時不釋放lock_log鎖，直到binlog被sync到磁盤中；

當備庫上表的列比主庫多一個自增列時，row模式下複制時，并沒有為該列遞增值(bug#69680)

禁止複制對performance scheama表的dml操作

切換semisync 打開/關閉狀态導緻的crash （bug#66411）

問題在于事務在committrx函數中，會先無鎖檢查semisync是否打開，然後在加鎖檢查，如果在加鎖之前semisync被disable，active_tranxs_會被清空，加鎖後目前線程判定semisync打開後，又會去判斷目前事務的位點是否被注冊(active_tranxs_-&gt;is_tranx_end_pos)，進而觸發斷言失敗

事實上這個fix在5.6.16版本上已經是多餘的了，因為在檢查active_tranxs_-&gt;is_tranx_end_pos之前已經預先判斷了是否打開了semisync：

當有多個dump線程時，可能導緻semisync的plugin lock沖突非常明顯，進而引發性能下降(bug#70218)

新的邏輯裡将semi dump線程的狀态傳回到server層，隻有在開啟了semisync的dump線程才去調用hook

the optimizer could push down a condition when the index did not have the key part present in the condition.

select distinct …group by可能傳回錯誤的結果集(bug#70657)

在子查詢裡進行all()+group by的聚合操作可能傳回錯誤的結果集（bug#71244）