時々、テーブルのインデックスが壊れてしまい、DBが100％のCPU負荷を消費してしまい、しばらく時間がかかりすぎてしまいます。単純なクエリでさえ完了せず、再起動しても役立たない。InnoDB：インデックスの破損と修正
私が見つけたのは、インデックスを1つずつ削除して再作成することです（これは時間がかかり、多くの調査が必要かもしれません）。疑わしいテーブルにalter table mytable engine=innodb;を呼び出すだけです。これは実際にはかなりうまく動作し、すべてが修正され、すべて正常に戻ります。しかし、私は実際に何がバックグラウンドで起こっているのか、なぜそれが役立つのか分かりません。また、手動で1か月に1回行うのも助かりますか？これを自動化することをお勧めしますか？いくつかのDBヘルスチェックを行う方法はありますか？
推測...
あなたは、MySQL/Percona、「永続的な統計を」持っていないか、それが有効になっていません。どちらか一方の古いバージョンを持っています。
あなたは間違ったクエリプランをオプティマイザが選択することがあるという厄介なクエリがあります。
遅いクエリでテーブルのANALYZE TABLEを実行することが、動作している場合と動作しない場合があります。
バージョンをアップグレードする方がよい場合があります。
一方、関連する各テーブルのクエリEXPLAINとSHOW CREATE TABLEを見てみましょう。それは、それほどフレークではないようにそれを再調整する方法かもしれない。
まあ、Perconaバージョン5.7.16-10があります。これはあまり古いものではありません。また、これはまったく異なるテーブル/クエリの前に私たちに起こりました。 'analyze table'から' OK'以外のものは一切ありませんでした。私は、 'alter table mytable engine = innodb;'が実行されたときに何が起こるか知りたいと思っています。これはいつも助けられていて、私はなぜそれがわからないのですか？ –
Alter..engineは 'OPTIMIZE'と同じです。 Analyzeは、「統計」を再計算するためのプローブをすばやく実行し、「OK」と表示します。私は、統計がクエリのために慌ててしまったと推測しています。 –
さて、すべてのテーブルで月に一度自動的に 'OPTIMIZE'を実行するのは安全でしょうか？ –
MySQLの最新バージョンを実行していますか？完全なダンプを試しましたか、DBのスクラッチビルドリストアを試しましたか？他のマシンで問題を再現できますか？バグの多いソフトウェアや不具合のあるハードウェアを扱っている可能性があります。 – tadman
はい、これはおおよそ年に1回、別のマシンにあった前回に発生します。私はDebianで最新のPerconaを実行しています。 –
MariaDBとMySQLを試してみて、それが問題であるか、ペルコナのサポートに連絡してみる価値があります。 – tadman