我有一个InnoDB数据表，这个数据表已经完美的工作了好几年，但是昨天两次失败了，可能是访问量增加的原因没有明显的原因，这个表locking了，有数百个DELETE REPLACE INTO查询（+ 500）与“更新”或“清理”状态。 （我没有更多的过程清单的副本…）
这个表格包含500到1500之间的几个条目，所以更新查询通常非常快并且不locking。
当问题发生时，我查了很多次这个进程列表，还没有看到任何明确locking表的查询。 实际上，我把我的网站设置为维护模式，所以没有更多的查询被添加到队列中，仍然有500多个查询，都是一样的：
+---------+---------+--------------+---------+---------+------+----------+-----------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +---------+---------+--------------+---------+---------+------+----------+-----------------------------------------------+ | 2780657 | XXXXXXX | XXXXXX:58199 | XXXXXXX | Query | 660 | updating | DELETE FROM connected WHERE time < 1272100968 | | 2764941 | XXXXXXX | XXXXXX:57314 | XXXXXXX | Query | 660 | updating | DELETE FROM connected WHERE time < 1272100968 | | 2784467 | XXXXXXX | XXXXXX:44221 | XXXXXXX | Query | 661 | updating | DELETE FROM connected WHERE time < 1272100969 | ...
我不知道我必须在哪里寻找这个问题的原因，并确定地解决这个问题。
但我想这可以给你一个更好的视觉问题：
mysql> show global status like "%innodb_row_lock%"; +-------------------------------+-----------+ | Variable_name | Value | +-------------------------------+-----------+ | Innodb_row_lock_current_waits | 0 | | Innodb_row_lock_time | 132004175 | | Innodb_row_lock_time_avg | 10521 | | Innodb_row_lock_time_max | 59373 | | Innodb_row_lock_waits | 12546 | +-------------------------------+-----------+ 5 rows in set (0.00 sec)
对不起，我可怜的英语，感谢您的帮助;-)
诀窍通常是find最长的查询，这是在show full processlist;标识的show full processlist; 您也可以使用像mytop这样的工具来按运行时sorting查询。
一旦隔离导致locking的查询，您可以尝试确定为什么locking。 在桌子上有没有改变造成写locking？ 有各种不同的情况，在大多数情况下，将涉及到一个应用程序问题。
如果没有主动排除故障，提供任何明确的build议是非常困难的。 至less，进一步的细节，如过程列表和应用程序将是有益的。