当mysqldump --single-transaction遇到alter table怎么办？

测试环境：

MySQL 5.5.14

在数据库testdb01下有表tb1001，当前表中存有两条数据：

##=========================================================##

发现竟然返回的是空集，没有任何报错。

这也就合理解释我同事操作的现象：在mysqldump过程中，修改表结构，修改操作没有被阻塞，mysqldump操作也”正常完成“。

由于SELECT /*!40001 SQL_NO_CACHE */ * FROM `tb1001`操作没有返回错误也没有返回数据，mysqldump进程会将tb1001当做一个空表来处理，然后继续导出后面的表直至导出所有的表然后返回执行成功的状态。但导出的备份已经缺失tb1001的数据，如果恰好采用该备份去恢复数据，那么必然最终导致“数据丢失”。

解决办法：

在对MySQL 5.5版本进行修改表操作前，先检查当前服务器是否在进行mysqldump操作，避免两者并行执行。

如果对mysqldump已经导出过的表进行修改操作，修改操作会被阻塞，直到mysqldump结束，该情况与MySQL 5.6版本一致。

总结：

对于MySQL 5.5版本，mysqldump与表修改操作同时执行：

如果修改表操作在 ”mysqldump开启后但还未导出修改表数据前“ 的时间段内开始，则修改表操作成功完成，而mysqldump不会执行失败，但是无法正常导出修改表的数据；

如果修改表操作在 “mysqldum已导出修改表数据但还未结束mysqldump操作前”的时间段内开始，则修改表操作被阻塞，mysqldum能成功完成，在mysqldump操作完成后修改表操作方可正常执行。

对于MySQL 5.5版本，应该避免mysqldump和修改表操作同时进行，以避免备份丢失修改表的数据，造成数据不一致！

# 的是  # 在对  # 这也  # 没有任何  # 两条  # 会将  # 报错  # 还未  # 时间段内  # 空集 

相关栏目： <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 AI推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 SEO优化<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 技术百科<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 谷歌推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 百度推广<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 网络营销<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 案例网站<？ｍｕｍａ echo $count; ?> 】 <？ｍｕｍａ $count = M('archives')->where(['typeid'=>$field['id']])->count(); ?> 【 精选文章<？ｍｕｍａ echo $count; ?> 】