淘宝数据库技术团队

由于线上主流MySQL数据库用的MySQL-5.1.48版本，这个版本运行近两年来，暴露的问题比较少，也是相对比较稳定的一个GA版本。最近研究升级到MySQL-5.1.x系列，发现没有找到能说服我自己的理由，除非是遇到了真的过不去的坎，或者特别想利用新的特性，因为从sysbench测性能试的结果看，不分伯仲。

	mysql-5.1.48		mysql-5.1.56
OPR	requests	latency	requests	latency
select	37331.96 37192.82	0.85 0.86	37396.46 37399.82	0.85 0.85
update-key	17305.59 17207.60	1.85 1.86	16855.06 16633.32	1.89 1.92
update-nokey	15517.05 15600.70	2.06 2.05	15258.13 14713.75	2.09 2.17
insert	9807.19 9892.62	3.26 3.23	11030.71 8748.67	2.90 3.65
delete	21095.04 21721.00	1.51 1.47	19690.32 22372.53	1.62 1.43
trx	19112.93 20660.41	31.8 29.5	24751.16 20814.12	24.57 29.25

 

 

 

 

 

 

 

 

 

 

 

 

看看Oracle对MySQL的规划，你会更倾向MySQL-5.5。但对于仍然使用MySQL-5.1.48的应用，必须要关注当前版本存在哪些问题。

下面是所列的几大主要版本修复的我们所关心的BUG，如有遗漏，后续补充。

 

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-49.html

暂无

 

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-50.html

#45012 my_like_range_cp932 generates invalid string （编码集，可以忽略）

#54117 crash in thr_multi_unlock, temporary table (debug版本存在)

#54465 assert: field_types == 0 || field_types[field_pos] == MYSQL_TYPE_LONGLONG(testcase好几个，但一直没有遇到)

 

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-52.html

暂无

 

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-52sp1.html

新特性innodb_use_sys_malloc=0|1

http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-performance-use_sys_malloc.html

#55421 Protocol::end_statement(): Assertion `0′ on multi-table UPDATE IGNORE （trigger执行时有活跃的select时会触发）

#55779 select does not work properly in mysql server Version “5.1.42 SUSE MySQL RPM”(当时间不是‘YYYY-MM-DD HH:MM:SS’格式时候，存在 >=只会查>的结果)

#50402 Optimizer producing wrong results when using Index Merge on InnoDB（join时可能存在，由于innodb在做index merge时逻辑错误导致）

 

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-53.html (FIXED TOO MANY BUGS IN REPLICATION)

#56982 Assertion Failure from ha_innobase::innobase_peek_autoinc() when auto_inc > 0 （alter table宕机后show create table OR information必然触发，当然前提是alter table后要宕机）

#55478 Row events wrongly apply on the temporary table of the same name (RBR要注意了)

#55375 Transaction bigger than max_binlog_cache_size crashes slave（仅仅在备库可能出现，因为备库的IO线程rollback所有事务，而不能仅仅rollback当前的stmt）

#55263 assert in check_binlog_magic (通过change master to改变relay log的信息时触发，因为没有清空IO_CACHE中内容导致读陈旧的数据)

#38718 slave sql thread crashes when reading relay log （invalid类型的binlog event导致备库crash）

#56423 Different count with SELECT and CREATE SELECT queries (create table … select要小心了)

 

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-54.html

几个不怎么关系的编译问题(Bug #57992, Bug #57993, Bug #57994, Bug #57995, Bug #57996, Bug #57997, Bug #58057)

#56228 The server could crash with an assertion error, if a stored procedure, stored function, or trigger modified one InnoDB table containing an auto-increment column, and dropped another InnoDB table containing an auto-increment column（修改autoinc列的DDL还是可能出现，做DDL的不要drop另外一个含autoinc的表）

 

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-55.html (seems good)

#18274 InnoDB auto_increment field reset on OPTIMIZE TABLE（optimize table要注意了,平常偶尔会用到）

#57288 binlog_tmp_table fails sporadically: “Failed to write the DROP statement …” （临时表关闭可能导致binlog错误，还没有遇到过）

 

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-56.html

 

#59308 Incorrect result for SELECT DISTINCT <col>… ORDER BY <col> DESC （线上还没有怎么注意到这个问题，重视下）

#59338 Inconsistency in binlog for statements that don’t change any rows STATEMENT SBR （对InnoDB来说，虽然binlog可能不一致，但对数据没有影响）