私は大規模なWPインスタンスを実行しています(現在、カスタムタイプでは28,000を超える投稿があります)。 MySQLスロークエリログを分析すると、問題のあるクエリの1つは次のとおりです。
SELECT COUNT(*) FROM wp_term_relationships, wp_posts
WHERE
wp_posts.ID = wp_term_relationships.object_id
AND post_status = 'publish'
AND post_type IN ('s5_video', 's5_post', 's5_one_liner', 's5_image')
AND term_taxonomy_id = 1498
(s5_video、s5_post、s5_one_liner、およびs5_imageは私たちのカスタムタイプです)
クエリに対してExplainを実行すると、次のようになります。
現在、分析された23,000行は多くありますが、それほどひどくはありません。特に、あまり頻繁に実行されない照会の場合はそうです。実際、私の手動テストでは、ほとんどの場合、クエリの実行にかかる時間は50ミリ秒程度です(おそらくそれはまだMySQLのクエリキャッシュにあるためです)。ただし、クエリの実行に12〜16 秒 かかることがあります。
私は二つの質問があると思います。
当社のミッドレンジVPSは、このタイプのクエリ(8 CPU、4GB RAM)を処理するための十分な能力を持っています。 SQL EXPLAINの結果は、MySQLが実際には結果を生成するためにキーを使用していることを示しています。私たちのサーバーの能力と、キーの使用を考えると、24k行を分析するのに12-16秒はちょっと極端に思えませんか? (それは約1500行です 毎秒 。やあ!)なぜこれが起こっているのでしょうか。これは他の誰かの大きなWPインスタンスで起きましたか?
何をすべきかについての提案はありますか?通常、このような状況では、処理速度を上げるためにインデックスを追加しますが、MySQLはすでに正しいキーを使用しています。そして私が言える限りでは、この問い合わせはWordpressのコア(私たちのカスタムコードの一部ではない)に組み込まれており、それをさらに最適化する方法を考えることができないほど十分簡単です。
不満足な答えのためにあなた自身を準備してください...
数日のテストの後、私がこれまでに出してきた結論は、簡単に言うと、これはWordpressの「障害」ではないということです。 _私は、サーバーに関する別の関連問題がシステム。これは単に遅いクエリの1つでした。サーバに負荷がかかっていたため、12〜16秒の間にスロークエリログの先頭にすぐに到達しました。
それは私が23,608 (VERY BAD, VERY SLOW)
の結合サイズに満足しているという意味ではありません。しかし、それはこの質問に遭遇する他の人たちにとって、あなたの特定の問題に対する解決策はあなたのシステム全体を調べて、なぜこの(または別の)クエリがそれほど良くないかを判断することかもしれません
ハッピーコーディング!