我们需要从不同的角度看问题

背景是某个业务的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_abandonquest

5.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;
						被阻塞…

经过上述分析后，是备份引起的死锁问题，所以，我只要把删档和备份时间点错开就好了，如此简单而已。

我们要学会从不同角度看待问题。