[原]我们需要从不同的角度看问题
linwaterbin发表于 2014-11-08 23:42:58
背景是某个业务的logdb历史oss_log(MyISAM表类型)例行删除，有时候会告"deadlock"。
当时我的第一反应是认为表很大，我并没有对这种一厢情愿的想法提出质疑，于是乎，我让运维找开发要了脚本，我希望通过优化脚本来优化执行时间！
吭叽吭叽的准备开搞，而且也很高兴的想到了优化脚本的方法.....
但从一开始我就没有从多个角度来看待这个问题，思维定式地认为这个是因为数据量大的原因。
下面这幅图从2个角度看得到的东西是南辕北辙啊
很多时候，在动手之前，先拿出笔和纸张，把问题认认真真分析一下，从不同角度会得到比较严谨而靠谱的方法，believe me！
分析slow log发现有些删除需要很长时间，比如：drop table 2014_10_17_oss_abandonquest 花费了15041.2410秒。删除行为在凌晨4点发出，刚好落在备份期间，因为5.5有了MDL（Meta data lock），所以–single-transaction时，事务内操作过的表都会持有MDL，因此不会被DDL破坏。所以，查看get_status.err会有如下日志：
11966363,hardcore,localhost,oss_log,Query,11084,Waiting for table metadata lock,drop table 2014_10_17_oss_abandonquest5.5的MDL机制是如果事务不释放，事务里边涉及到的表都会持有该表的DML锁，事务不释放，锁就不释放。而5.0、5.1的MDL机制与事务无关，只要语句结束，语句持有的MDL锁就会释放。这是两者的区别，确实该表引擎没关系。
下面是个测试：
下面是个测试：
| session.1 | session.2 | |||||||
| Step.1 | begin; | |||||||
| Step.2 | select * from tb_myisam; | |||||||
| Step.3 | drop table tb_myisam; | |||||||
| 被阻塞… | ||||||||
经过上述分析后，是备份引起的死锁问题，所以，我只要把删档和备份时间点错开就好了，如此简单而已。
我们要学会从不同角度看待问题。