我试图发现为什么mysqld有时会使cpu和摊位饱和。
我怀疑这与更新索引或其他此类维护有关。我想证明这个假设并考虑避免它的选择。
这是情况。我有几十个表，但根据活动，似乎至少有两个表一直受此影响。我们称他们为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都需要20个 gigacycles （！）;之后的那个根本没有时间。还有其他表对这两个表都有外键，但是它们都相当小，我认为它们不对这个峰值负责。
如何找出MySQL正在更新的索引以及每个索引需要多长时间？
或者，如果它没有更新索引，我怎么能找出其他什么花了这么长时间？
最后，我可以设置mysqld来为这项工作提供较低的线程优先级，和/或暂时禁用索引以允许非索引（非阻塞）选择与维护任务同时发生吗？
答案 0 :(得分：2)
您可能会看到的另一个诊断工具是mytop。它基本上是SHOW PROCESSLIST的包装器，但是当你发现问题发生并且没有mysql cli方便/可用于运行命令时，它可以更快地访问这些数据。
答案 1 :(得分：1)
可能有一个更好的解决方案，但我之前遇到过这样的情况：我需要找到偶尔使用大量CPU的db / table。我cronjobbed一个“show processlist”并将输出附加到滚动日志。我每秒都这样做，并保持6个小时的滚动窗口。