5
我试图发现mysqld为什么有时饱和CPU和摊位。诊断和避免MySQL的CPU峰值
我怀疑它的东西做更新指标或其他这样的维护。我想证明这个假设，并考虑避免它的选择。
这是情况。我有几十张桌子，但基于活动，似乎至少有两个一直遭受这种情况。我们称它们为Big和Small。 Big包含大约6,000行总计1Mb（所以不是全部那么大）和Small有几十行，每个大约50字节。 Big有一个外键Small（InnoDB，删除级联，不为空）。
有两种情况似乎会触发问题：a）修改Big.small_id值，或者b）向Small添加一行。
我会直觉地想到一个）是非常该死的快，O(log(size of Big))和b）是几乎瞬间因为Small是如此之小，没有Big的引用，它已经改变。在每种情况下，随后的SELECT都需要类似于二十个gigacycles（！）;那之后的那一刻完全没有时间。还有其他的表都有这些表的外键，但都是相当小的，我认为他们不负责这个高峰。
我如何可以找出哪些索引MySQL正在更新和各需要多长时间？
或者，如果没有更新索引，我怎么可以找出还有什么是要花这么长时间？
最后，我可以设置mysqld为这项工作赋予低线程优先级，和/或临时禁用索引以允许非索引（非阻塞）选择与维护任务同时发生？
SHOW PROCESSLIST显示，查询是在“发送数据”状态很长时间。这并不比描述更具描述性。我怀疑这是一个公平的标签，因为我在本地主机上，传输不应该是瓶颈。我从哪里出发？谢谢 – spraff 2012-03-23 14:05:03