为什么一个简单的 MySQL 更新查询有时需要几分钟？答案

【问题标题】：Why would a simple MySQL update query occasionally take several minutes?为什么一个简单的 MySQL 更新查询有时需要几分钟？
【发布时间】：2010-02-12 15:07:56
【问题描述】：

我有一个庞大的数据库服务器，其中包含许多非常相似的 InnoDB 数据库。我经常运行的查询只是更新小表中一行的时间戳。大部分时间这需要 1-2 毫秒。有时，在晚上，可能在备份和 maatkit 复制工具正在运行时，这些查询中的一个或多个可能会在几分钟内显示“正在更新”。在此期间，其他查询，包括 maatkit 查询，似乎都在正常进行，似乎没有其他查询在执行。我无法解释或解决此问题。

我们在一对 4-way Xeon 上使用 mysql 4.1.22 和 gentoo 2.6.21，具有 16gig 的 RAM 和 RAID 驱动器用于存储。复制已经到位并且运行良好，maatkit 每晚确认复制。 InnoDB 正在使用大部分 RAM，并且 cpu 通常处于 70-80% 的空闲状态。有问题的表有大约 100 行，每行大约 200 个字节。我已经尝试过在 WHERE 子句上使用和不使用索引，但没有明显的变化。未发现异常日志消息（检查系统消息和 mysql 错误）。

还有其他人听说过吗？解决了这样的事情？关于如何调查的任何想法？

【问题讨论】：

标签： mysql mysql-management

【解决方案1】：

在进行DML 操作时，InnoDB 会在行和索引间隙上加锁。

问题在于它锁定了所有检查行，而不仅仅是那些受影响。

说，如果你运行这个查询：

UPDATE  mytable
SET     value = 10
WHERE   col1 = 1
        AND col2 = 2

，锁定将取决于用于查询的索引：

如果使用了col1, col2 上的索引，则只会锁定受影响的行
如果使用了col 上的索引，则所有带有col1 = 1 的行都将被锁定
如果使用了col2 上的索引，则所有带有col2 = 2 的行都将被锁定
如果没有使用索引，所有行和索引间隙都将被锁定（包括PRIMARY KEY 上的，这样即使INSERT 到AUTO_INCREMENT 列也会锁定）
李>

更糟糕的是，MySQL 中的 EXPLAIN 不适用于 DML 操作，因此您必须猜测使用了哪个索引，因为优化器可以选择任何认为最好的索引。

因此，您的复制工具和更新可能会同时锁定记录（如您所见，即使WHERE 条件不重叠，这种情况也可能发生）。

【讨论】：

那么进程列表不会显示“锁定”吗？我有一个“显示完整进程列表”，显示 maatkit 在一个数据库上工作，其中一个简单的更新查询在第二个数据库上“更新”，另一个相同的简单更新查询在第三个数据库上“更新”，并且没有其他查询正在运行.我没有发布流程列表，因为它包含我必须编辑的客户名称。
@PaulC: SHOW PROCESSLIST 不显示Locked 用于InnoDB 表，仅用于MyISAM。即使针对InnoDB 表的操作正在等待锁定，它仍将显示为Updating。
知道 InnoDB 在真正“锁定”时会显示“正在更新”是非常有帮助的。禁用 maatkit 的重新同步暂时停止了问题，所以看起来 maatkit 确实锁定了一段时间。还在调查中……

【解决方案2】：

如果您可以在此查询挂起时访问服务器，请尝试执行“显示 innodb 状态”。您从中获得的混乱数据的一部分是 InnoDB 表上所有活动连接/查询的状态。如果您的查询因另一笔交易而挂起，则会在此处显示。有锁数据样本here。

同样，您提到它似乎发生在备份过程中。你为此使用mysqldump吗？这将在转储处于活动状态时锁定表，以便转储的数据保持一致。

【讨论】：

【解决方案3】：

使用回复中提供的一些信息，我们继续调查并在我们的服务器上发现了一些令人不安的行为。任何数据库中任何表的简单“检查表”都会导致简单的更新查询锁定其他数据库和其他表。我不知道为什么会发生这种情况，虽然我们无法在 MySQL v5.1 上重现它，所以我们打算升级我们的数据库服务器。

我不认为 maatkit 的 mk-table-checksum 做“检查表”，但它具有类似的效果。关闭此脚本可显着减少问题，但我们相信没有此脚本我们将无法生存。

我将把它标记为我的问题的答案。感谢您的帮助。

【讨论】：