mysql - 诊断并避免 MySQL CPU 峰值

Question

我试图发现为什么 mysqld 有时会使 cpu 饱和并停止。

我怀疑这与更新索引或其他此类维护有关。我想证明这个假设并寻找避免它的选项。

情况是这样的。我有几十张 table ，但根据事件，似乎至少有两张 table 一直受到这种影响。我们称它们为 Big 和 Small。 Big 包含大约 6,000 行，总计 1Mb(所以不是那么大)，Small 包含几十行，每行大约 50 个字节。 Big 有一个指向 Small 的外键(InnoDB，在删除级联时，不为空)。

似乎有两种情况会触发该问题:a) 修改 Big.small_id 值，或 b) 添加一行到 Small。

我直觉上希望 a) 非常快，O(log(size of Big)) 和 b) 几乎是即时的，因为 Small 太小了Big 对它的引用都没有改变。

在每种情况下，后续的 SELECT 都需要大约二十个 gigacycles (!)；之后的一个根本不需要时间。还有其他表具有这两个表的外键，但它们都相当小，我认为它们不应对此峰值负责。

我如何找出 MySQL 正在更新哪些索引以及每个索引需要多长时间？

或者，如果它不更新索引，我如何才能找出其他什么花费了这么长时间？

最后，我能否设置 mysqld 为这项工作提供较低的线程优先级，和/或暂时禁用索引以允许非索引(非阻塞)选择与维护任务同时发生？

Answer 1

您可能会查看的另一个诊断工具是 mytop .它基本上是 SHOW PROCESSLIST 的包装器，但当您发现问题发生并且没有方便/可用的 mysql cli 来运行命令时，它可以更快地访问此数据。

另外，看看:MySQL "Sending data" horribly slow