MySQL kill进程后出现killed死锁

问题现象

有一张3亿的表，现在要对这张表进行删除1亿行，于是有人开始运行delete from table limit 100000000;毫无疑问这是一个愚蠢的删除方式，于是有人开始变更删除方式：delete from table where id<100000000;然而运行一段时间后，又发现批量删除的效率可能会更高，所以kill掉了上一条运行了一段时间的sql，开始批量删除， 由于是大sql，晚上点击运行想第二天早上来看结果的DBA就会遗憾的发现新执行的sql被锁给挡了回来，并没有运行，导致浪费了一晚上的时间。但是盲目的等待锁释放心里没底，所以我们可以通过下面的方式计算出这个锁什么时候能够释放，我们就可以使用表了。

场景：
一个巨大的delete语句 执行一小时后kill ，show processlist出现killed进程 ，不要盲目重启！ 重启MySQL后进程消失但锁依然存在！重启MySQL后进程消失但锁依然存在，因为回滚还要继续，这是mysql对数据的保护机制。

通过下列语句查询事务情况：

# trx_rows_modified 代表锁影响的行数，当数值为0时，锁将会释放
SELECT * FROM information_schema.INNODB_TRX

# 查看表锁信息
SELECT * FROM information_schema.INNODB_LOCKS
SELECT * FROM information_schema.INNODB_LOCK_waits

结论

时间过长的update、delete等语句在kill之后会进行回滚操作，会锁表，经常有人更换不同方式对大数据进行修改删除，然而盲目的杀死正在长时间运行的进程后并不能马上对表进行新的操作，后果只能是等待之前的操作回滚结束，本想用更快的方式操作表结果得不偿失，所以还是建议选择好对表修改操作方式然后一次运行，不再修改。