私はWPベースのサイトのスロークエリログを追跡しており（a long_query_timeのデフォルト値は10に設定されています）、次のクエリが頻繁に記録されることに気付きました-
# User@Host: root[root] @ localhost []
# Query_time: 0 Lock_time: 0 Rows_sent: 394 Rows_examined: 458
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';
このような小さなテーブルを実行するのにそれほど時間がかかることがわかりません。これは単に他の問題の症状ですか？（現在、専用VMでMoodle、phpbb、およびWPを実行しています）。
回答:
更新：クエリがログに記録される理由は、インデックスを使用しないためです。クエリ時間は0です。つまり、実際には高速に実行されます。これらをログに記録したくない場合は、「log-queries-not-using-indexes」オプションの設定を解除できます。
wp_optionsテーブルには自動ロードに関するインデックスがないため、クエリは最終的に全テーブルスキャンを実行します。一般に、そのテーブルが大きくなりすぎないように、それは問題ではありませんが、私はそれが何らかの形であなたの場合に起こったと推測しています。
インデックスを追加すると問題が解決する可能性がありますが、TheDeadMedicがコメントで指摘したように、autoloadの値が過半数yesであるか、yeとnoの間で均等に分散している場合はそうではありません。
まず、このクエリを実行して、分布がどのように見えるかを確認します。
SELECT COUNT(*), autoload FROM wp_options GROUP BY autoload;それらの大部分が「いいえ」に設定されている場合は、自動ロード時にインデックスを追加することで問題を解決できます。
ALTER TABLE wp_options ADD INDEX (`autoload`);ただし、そのテーブルが大きくなりすぎた理由の一番下に到達したい場合があります。恐らく何かひどいことをしているいくつかのひどく書かれたプラグイン。
wp_optionsテーブルには、約235行のデータしかありませんでした。テーブルのインデックスを作成しようとしましたが、役に立ちませんでした。
約150の一時的なオプションがテーブルに挿入されたが、自動的に削除されていなかったことが判明しました。
それが関連しているかどうかはわかりませんが、/ var / log / apache2 / access.logファイルを調べて、複数の（おそらく侵害された）Amazon Web Servicesサーバー（54で始まるIPアドレス）に気付きました。 XXXおよび32.XXX）は、/〜web-root-dir / xmlrpc.phpを悪用しようとしていました。
いくつかのトラブルシューティングの後、「一時的」を含むオプション名についてwp_optionsテーブルを照会しました
select * from wp_options where option_name like '％transient％';
このクエリから返されるフィールドの1つは、LONGTEXTのデータ型を持つ「option_value」です。mySQLのドキュメントによると、LONGTEXTフィールド（各行）は最大4ギガバイトのデータを保持できます。
私は、クエリを実行すると、行の一部は（「一過性」を含むものを使用していたのを覚えて）持っていた大規模な option_valueフィールド内のデータの量を。結果を見ると、cronサイクル中にコマンドが実行されることを期待して、wp-cronプロセスにコマンドを挿入しようとする試みのようにも見えました。
私の解決策は、すべての「一時的な」行を削除することでした。「一時的な」行が自動的に再配置されるため（これが存在することになっている場合）、サーバーを傷つけることはありません。
これを実行した後、サーバーは再び応答しました。
これらの行を削除するクエリ：
option_nameが '％transient％'のようなwp_optionsから削除します。
ファイアウォールにもAWS IPアドレス/ 8スーパーブロックを追加しました（-：