InnoDB：破坏和修复索引

有时我们的表中的某些索引被破坏，数据库开始消耗100％的CPU负载，并在一段时间内完全卡住。即使简单的查询也无法完成，重新启动也无济于事。InnoDB：破坏和修复索引

我发现的是要么逐个删除并重新创建索引（这可能需要很长的时间和很多调查），或者只是在可疑表上调用alter table mytable engine=innodb;。这实际上很好，它修复了一切，一切恢复正常。但我不知道背景中究竟发生了什么，以及它为什么会有所帮助。另外 - 它会帮助每月手动进行一次吗？自动化这是一个好主意吗？有没有办法做一些数据库健康检查？

来源

2017-09-27 Vojtěch

您是否正在运行最新版本的MySQL？你有没有试过一个完整的转储，从零开始恢复你的数据库？你能在任何其他机器上重现问题吗？你可能正在处理有问题的软件或有缺陷的硬件，例如一大堆内存。 – tadman

是的，这大概发生一年，最后一次发生在不同的机器上。我正在Debian上运行最新的Percona。 –

值得尝试一下MariaDB和MySQL，看看它是否是问题和/或联系Percona支持。 – tadman

猜...

你的MySQL/Percona的，一个旧版本的，不具有“持续性统计”或没有启用它要么。

而且您有一个讨厌的查询，有时会导致优化器选择错误的查询计划。

快速修复（可能或可能不起作用）是在缓慢查询中运行表（s）的ANALYZE TABLE。

更好的修复方法可能是升级版本。

同时，让我们看看查询，其EXPLAIN和SHOW CREATE TABLE为涉及的每个表。这可能是一种将其重新制作成不那么脆弱的方法。

来源

2017-09-27 22:38:30

那么，我们有Percona版本5.7.16-10，这不应该太老。前一段时间，我们也遇到过完全不同的表/查询。从'分析表'我从来没有任何东西比'好'。我想知道当执行“alter table mytable engine = innodb;”时会发生什么。这总是有帮助，我不知道为什么。 –

改变..引擎和'OPTIMIZE'一样。快速分析一些探测重新计算“统计”，然后说“确定”。我认为统计数据已经不符合查询条件。 –

好吧，在所有桌子上每月自动运行一次OPTIMIZE会安全吗？ –

InnoDB：破坏和修复索引

回答

相关问题