今天和 51.com 的 mysql dba 景春同学一起遇到了个 mysql 非常扯淡的bug：在 5.1 版本中，innodb 存储引擎如果使用autocommit=0的情况下，单条sql在执行过程中如果异常中断的话，事务完整性可能无法保证，不论是statement还是mixed的binlog_format，都存在相
今天和 51.com 的 mysql dba 景春同学一起遇到了个 mysql 非常扯淡的bug：在 5.1 版本中，innodb 存储引擎如果使用autocommit=0的情况下，单条sql在执行过程中如果异常中断的话，事务完整性可能无法保证，不论是statement还是mixed的binlog_format，都存在相同的问题，可以重现，屡试不爽。
测试环境如下：
os：sunos 5.10 generic_137138-09
db：mysql 5.1.31/32-log source distribution
binlog_format:mixed/statement
tx_isolation:repeatable-read
测试脚本如下：
[root@dc-5 /tmp]#cat deletetest.sh
#/bin/sh
mysql -uadmin -h127.0.0.1 -pxxx -eset autocommit=0;delete from test.test;
[root@dc-5 /tmp]#cat killtest.sh
#/bin/sh
mysqladmin -uroot processlist |grep admin|awk '{print $2}'|xargs mysqladmin -uroot kill
将删除的脚本放到后台执行，然后执行kill脚本：
[root@dc-5 /tmp]#time ./deletetest.sh &
[1] 6708
[root@dc-5 /tmp]#./killtest.sh
error 1053 (08s01) at line 1: server shutdown in progress
real    0m2.901s
user    0m0.007s
sys     0m0.007s
[root@dc-5 /tmp]#
[1]+  exit 1                  time ./deletetest.sh
到master 和 slave 两端分别检查数据，看上去很正常：
root@dc-5 : (none)01:35:43> selectcount(*)fromtest.test;
+----------+
| count(*) |
+----------+
| 1000000|
+----------+
1rowinset(1.71sec)
root@dc-6 : (none)01:36:01> selectcount(*)fromtest.test;
+----------+
| count(*) |
+----------+
| 1000000|
+----------+
1rowinset(1.69sec)
我们再将set autocommit=0拿掉试试看，也就是允许系统自动提交：
[root@dc-5 /tmp]#cat deletetest.sh
#/bin/sh
mysql -uadmin -h127.0.0.1 -pxxx -edelete from offer1.test;
[root@dc-5 /tmp]#time ./deletetest.sh &
[1] 6722
[root@dc-5 /tmp]#./killtest.sh
[root@dc-5 /tmp]#error 1053 (08s01) at line 1: server shutdown in progress
real    0m2.462s
user    0m0.006s
sys     0m0.007s
[1]+  exit 1                  time ./deletetest.sh
再检查 master 和 slave 两端的数据：
root@dc-5 : (none)01:40:30> selectcount(*)fromoffer1.test;
+----------+
| count(*) |
+----------+
|  887377 |
+----------+
1rowinset(1.66sec)
root@dc-6 : offer101:44:05>  selectcount(*)fromoffer1.test;
+----------+
| count(*) |
+----------+
| 1000000|
+----------+
1rowinset(1.70sec)
master 和 slave 两端数据居然出现不一致，在 master 端已经删除掉了部分数据，在 slave 端却没有任何变化。执行 deletetest.sh 脚本前后检查 master 的 binary log（show master status），没有任何变化。这个 bug 简直是太扯淡了，数据完全没有事务完整性可言了啊。
原文地址：mysql5.1 中innodb事务完整性bug, 感谢原作者分享。