MySQL · 談古論今· key分區算法演變分析 · 數據庫內核月報

本文說明一個物理升級導致的 "數據丟失"。 **現象** 在mysql 5.1下新建key分表，可以正確查詢數據。 ~~~ drop table t1; create table t1 (c1 int , c2 int) PARTITION BY KEY (c2) partitions 5; insert into t1 values(1,1785089517),(2,null); mysql> select * from t1 where c2=1785089517; +------+------------+ | c1 | c2 | +------+------------+ | 1 | 1785089517 | +------+------------+ 1 row in set (0.00 sec) mysql> select * from t1 where c2 is null; +------+------+ | c1 | c2 | +------+------+ | 2 | NULL | +------+------+ 1 row in set (0.00 sec) ~~~ 而直接用mysql5.5或mysql5.6啟動上面的5.1實例，發現(1,1785089517)這行數據不能正確查詢出來。 ~~~ alter table t1 PARTITION BY KEY ALGORITHM = 1 (c2) partitions 5; mysql> select * from t1 where c2 is null; +------+------+ | c1 | c2 | +------+------+ | 2 | NULL | +------+------+ 1 row in set (0.00 sec) mysql> select * from t1 where c2=1785089517; Empty set (0.00 sec) ~~~ **原因分析** 跟蹤代碼發現，5.1 與5.5,5.6 key hash算法是有區別的。 5.1 對于非空值的處理算法如下 ~~~ void my_hash_sort_bin(const CHARSET_INFO *cs __attribute__((unused)), const uchar *key, size_t len,ulong *nr1, ulong *nr2) { const uchar *pos = key; key+= len; for (; pos < (uchar*) key?; pos++) { nr1[0]^=(ulong) ((((uint) nr1[0] & 63)+nr2[0]) * ((uint)*pos)) + (nr1[0] << 8); nr2[0]+=3; } } ~~~ 通過此算法算出數據(1,1785089517)在第3個分區 5.5和5.6非空值的處理算法如下 ~~~ void my_hash_sort_simple(const CHARSET_INFO *cs, const uchar *key, size_t len, ulong *nr1, ulong *nr2) { register uchar *sort_order=cs->sort_order; const uchar *end; /* Remove end space. We have to do this to be able to compare 'A ' and 'A' as identical */ end= skip_trailing_space(key, len); for (; key < (uchar*) end?; key++) { nr1[0]^=(ulong) ((((uint) nr1[0] & 63)+nr2[0]) * ((uint) sort_order[(uint) *key])) + (nr1[0] << 8); nr2[0]+=3; } } ~~~ 通過此算法算出數據(1,1785089517)在第5個分區，因此，5.5,5.6查詢不能查詢出此行數據。 5.1,5.5,5.6對于空值的算法還是一致的,如下 ~~~ if (field->is_null()) { nr1^= (nr1 << 1) | 1; continue; } ~~~ 都能正確算出數據(2, null)在第3個分區。因此，空值可以正確查詢出來。那么是什么導致非空值的hash算法走了不同路徑呢？在5.1下，計算字段key hash固定字符集就是my_charset_bin，對應的hash 函數就是前面的my_hash_sort_simple。而在5.5，5.6下，計算字段key hash的字符集是隨字段變化的，字段c2類型為int對應my_charset_numeric，與之對應的hash函數為my_hash_sort_simple。具體可以參考函數Field::hash 那么問題又來了，5.5后為什么算法會變化呢？原因在于官方關于字符集策略的調整，詳見[WL#2649](http://dev.mysql.com/worklog/)?。 **兼容處理** 前面講到，由于hash 算法變化，用5.5，5.6啟動5.1的實例，導致不能正確查詢數據。那么5.1升級5.5,5.6就必須兼容這個問題.mysql 5.5.31以后，提供了專門的語法 ALTER TABLE ... PARTITION BY ALGORITHM=1 [LINEAR] KEY ...? 用于兼容此問題。對于上面的例子，用5.5或5.6啟動5.1的實例后執行 ~~~ mysql> alter table t1 PARTITION BY KEY ALGORITHM = 1 (c2) partitions 5; Query OK, 2 rows affected (0.02 sec) Records: 2 Duplicates: 0 Warnings: 0 ~~~ ~~~ mysql> select * from t1 where c2=1785089517; +------+------------+ | c1 | c2 | +------+------------+ | 1 | 1785089517 | +------+------------+ 1 row in set (0.00 sec) ~~~ 數據可以正確查詢出來了。而實際上5.5,5.6的mysql_upgrade升級程序已經提供了兼容方法。mysql_upgrade 執行check table xxx for upgrade 會檢查key分區表是否用了老的算法。如果使用了老的算法，會返回 ~~~ mysql> CHECK TABLE t1 FOR UPGRADE\G *************************** 1\. row *************************** Table: test.t1 Op: check Msg_type: error Msg_text: KEY () partitioning changed, please run: ALTER TABLE `test`.`t1` PARTITION BY KEY /*!50611 ALGORITHM = 1 */ (c2) PARTITIONS 5 *************************** 2\. row *************************** Table: test.t1 Op: check Msg_type: status Msg_text: Operation failed 2 rows in set (0.00 sec) ~~~ 檢查到錯誤信息后會自動執行以下語句進行兼容。 ~~~ ALTER TABLE `test`.`t1` PARTITION BY KEY /*!50611 ALGORITHM = 1 */ (c2) PARTITIONS 5。 ~~~