本文说明一个物理升级导致的 "数据丢失"。
现象
在mysql 5.1下新建key分表，可以正确查询数据。
而直接用mysql5.5或mysql5.6启动上面的5.1实例，发现(1,1785089517)这行数据不能正确查询出来。
原因分析
跟踪代码发现，5.1 与5.5,5.6 key hash算法是有区别的。
5.1 对于非空值的处理算法如下
通过此算法算出数据(1,1785089517)在第3个分区
5.5和5.6非空值的处理算法如下
通过此算法算出数据(1,1785089517)在第5个分区，因此，5.5,5.6查询不能查询出此行数据。
5.1,5.5,5.6对于空值的算法还是一致的,如下
都能正确算出数据(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 。
兼容处理
前面讲到，由于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的实例后执行
数据可以正确查询出来了。
而实际上5.5,5.6的mysql_upgrade升级程序已经提供了兼容方法。mysql_upgrade 执行check table xxx for upgrade 会检查key分区表是否用了老的算法。如果使用了老的算法，会返回
检查到错误信息后会自动执行以下语句进行兼容。
