web-dev-qa-db-ja.com

SQL_CALC_FOUND_ROWSクエリが遅い

WordPressの管理セクション内でSQL_CALC_FOUND_ROWSを使用するクエリで非常に遅いパフォーマンスを経験しています。

現在私たちのサイトには約125,000の投稿があり、フロントエンドをキャッシュするためにVarnishを使用しており、WordPressバージョン4.2.3にあります。

WordPressのadminセクションを使用している人がいると問題が発生し、WordPressは以下のようなクエリを実行します。

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID 
FROM wp_posts 
WHERE 1=1 AND (((wp_posts.post_title LIKE '%denali%') 
OR (wp_posts.post_content LIKE '%denali%'))) 
AND wp_posts.post_type = 'post' 
AND (wp_posts.post_status = 'publish' 
OR wp_posts.post_status = 'future' 
OR wp_posts.post_status = 'draft' 
OR wp_posts.post_status = 'pending' 
OR wp_posts.post_status = 'private') 
ORDER BY wp_posts.post_title LIKE '%denali%' DESC, 
wp_posts.post_date DESC LIMIT 0, 20

この問題を修正するためのパッチ、または実行可能なある種のpre_get_postsフィルタはありますか。

私はいくつかのポストリビジョンを削除し、DBを最適化することを計画していますが、最初にWordPress内でこれに対する何らかの修正があるかどうかを確認したいと思いました。

私はこれを探している間に同様の問題に出くわしました、しかし、それらの問題のほとんどは2 - 6歳であるようです。

wp-querydatabasemysqlperformancepre-get-posts
4
bigmike7801

SQL_CALC_FOUND_ROWSの使用はオーバーヘッドを招きますが、実際には問題になりません。

何が起こるかというと、LIMIT節が指定されていない場合、WordPressは返されるはずだった投稿の総数を判断するためにSQL_CALC_FOUND_ROWSを使用します。これは、正しいページネーションリンクを計算して提供するために必要です。

無条件にそれを無効にすることは至る所で物事を破ることが保証されています。

その使用に悩まされている特定のクエリを識別でき、そしてページネーションなしで行うことができるなら、あなたはpre_get_postsにフックし、条件付きでno_found_rowsパラメータをtrueに設定することができます。しかし、これは解決策よりもハックです。

適切な解決策は、データベース側で、または Advanced Post Cache （WordPress.com用に開発され使用されている）などのプラグインを使用して、WordPress側でデータベースクエリキャッシングメカニズムを使用することです。

1
Anastis