标签：自动 5.6 查询 延迟 ase form where 场景 查询日志
场景:mysql> show open TABLES where In_use >0;
+----------+---------------+--------+-------------+
| Database | Table | In_use | Name_locked |
+----------+---------------+--------+-------------+
| cxx | t_post_xxxxxx | 1 | 0 |
+----------+---------------+--------+-------------+结论
从库没有线程，说明锁定的表是从主库同步过来的语句锁定的，应该是主库对此表的大事务操作造成。
分析
1.通过show slave status 确定的position去分析主库的binlog，发现生成了大量的删除 t_post_xxxxxx的语句；
2.查看慢查询日志，发现 delete from t_post_xxxxxx;
3.在主库查看 t_post_xxxxxx表结构，发现竟然没有主键也没有索引；
4.select count(*) from t_post_xxxxxx;发现此表20多万条数据；
5.真相大白了，没有主键直接delete删除全表会生成20多万条delete语句在binlog中，没有主键同步到从库需要执行20多万次全表扫描，20W*20W=400多亿，吓人！；
6.MySQL同步的时候, 会去利用主键来搜索需要修改的行(或者是一些二级索引)。
解决方案
1.增加主键；
2.跟研发沟通delete from t_post_xxxxxx改为truncate table t_post_xxxxxx。
综上
由于没有统一数据库上线平台和代码审核机制，造成一些不规范的代码以及数据库设计在生产运行。建议上线使用规范化的数据库上线平台，由平台自动发现数据库设计、数据库上线脚本问题，靠人肉上线难免会有疏漏，自动化运维势在必行，研发团队要使用代码规范检查工具避免不规范的代码上线。
binlog_format=ROW模式下mysql表无主键造成的从库延迟（卡住）
标签：自动 5.6 查询 延迟 ase form where 场景 查询日志
原文地址：http://blog.51cto.com/175779/2309757
