こんにちは、AIシステムズです。
この記事は、代表コバが現場で対応してきたデータベース運用の知見をもとに、AIを活用して構成・執筆し、弊社にて最終チェックを行ったものです。
「サイトの特定ページだけ表示が遅い」「管理画面の一覧が開くのに10秒かかる」——その原因の大半はMySQLクエリのインデックス未使用やN+1問題です。サーバーのスペックを上げる前に、まずクエリの実行計画を見れば、コストをかけずに解決できるケースがほとんどです。
- 遅いクエリを特定する方法
- EXPLAINで実行計画を読む
- インデックスの貼り方と落とし穴
- WordPressサイトでよくある遅いクエリ
- サーバー増強の前にやるべきこと
目次
- 遅いクエリの特定方法
- EXPLAINで実行計画を読む
- インデックスの設計
- WordPressサイトでよくある事例
- こういうサイトに向いている／向いていない
- 再発防止チェックリスト
遅いクエリの特定方法
最初にやるべきは、感覚ではなく数字で遅いクエリを特定することです。MySQLのスロークエリログを有効にします。
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';1秒以上かかるクエリをすべて記録し、mysqldumpslow で集計します。
mysqldumpslow -s t /var/log/mysql/slow.log | head -20これで「合計実行時間が長いクエリTOP20」が出ます。チューニングはこのリストの上から順に取り組むのが最も効率的です。
EXPLAINで実行計画を読む
特定したクエリの先頭に EXPLAIN をつけて実行し、MySQLが内部でどう動くかを確認します。
EXPLAIN SELECT * FROM wp_posts WHERE post_status = 'publish' AND post_type = 'tips' ORDER BY post_date DESC LIMIT 10;注目すべき項目は次の3つです。
type：ALLなら全件スキャン（最悪）、refやrangeならインデックス使用rows：MySQLが読みに行く推定行数。何百万行になっているなら要対応Extra：Using filesortやUsing temporaryが出ていれば、ソート用のインデックスが足りない
type が ALL でかつ rows が大きいクエリは、ほぼ確実にインデックスで改善できます。
インデックスの設計
インデックスは「WHERE・ORDER BY・JOINで使うカラム」に貼ります。複数カラムを使う場合は複合インデックスを検討します。
CREATE INDEX idx_status_type_date
ON wp_posts (post_status, post_type, post_date);複合インデックスは「左から順に使われる」のがポイントです。(A, B, C) のインデックスは、WHEREで A 単独、A AND B、A AND B AND C なら使えますが、B 単独や B AND C では使えません。
落とし穴として、インデックスを貼りすぎるとINSERT・UPDATEが遅くなるため、使われていないインデックスは sys.schema_unused_indexes で定期的に確認して削除します。
WordPressサイトでよくある事例
弊社が中小企業のWordPress保守で対応してきた中で、特に多いのは次のパターンです。
wp_postmetaのmeta_key+meta_valueで検索しているが、meta_valueがTEXT型でインデックスが効かない- カスタム投稿一覧で
posts_per_page=-1（全件取得）が指定されていて、件数が増えると爆発的に遅くなる - プラグインが管理画面で
wp_optionsの autoload を大量に追加し、毎ページの先頭で重いクエリが走る - ACFで多数のカスタムフィールドを使い、1ページの表示で
wp_postmetaへ数百回SELECTが走る
最後のN+1問題は、get_field() を get_fields()（複数フィールド一括取得）に置き換える、あるいは update_post_meta_cache() を呼んで一括キャッシュさせることで解消できます。
サーバー増強の前にやるべきこと
- スロークエリログでTOP20を特定
- EXPLAINで実行計画を確認
- インデックスを追加または見直し
- 不要なautoload、不要なプラグインを削減
- 必要に応じてクエリキャッシュ・オブジェクトキャッシュを導入
この5つで多くの中小企業サイトは、サーバーのプランを上げずに体感速度が大きく改善します。
こういうサイトに向いている／向いていない
このチューニング手法は、データ量が増えてきて表示が遅くなった中小企業のWordPressサイトや業務システムに直接効きます。月間PVが少なく、データも数百件レベルのサイトでは、ここまでの手間をかける必要はありません。
再発防止チェックリスト
- スロークエリログが有効になっているか
- 主要クエリにEXPLAINをかけた記録があるか
- WHERE・ORDER BYで使うカラムにインデックスがあるか
- 使われていないインデックスを定期的に棚卸ししているか
wp_optionsのautoloadサイズを定期的に確認しているか
まとめ
MySQLクエリの遅さは、サーバーのスペックではなくインデックスとクエリ構造で決まります。スロークエリログ→EXPLAIN→インデックス追加の流れを習慣にすれば、コストをかけずに体感速度を改善できます。
本記事は、代表コバが中小企業のデータベース運用の現場で対応してきた知見をもとに、AIを活用して構成・執筆し、弊社にて最終確認を行っています。サイトの表示速度改善、データベースチューニング、WordPress保守の見直しについて、具体的な状況をふまえた相談を承っています。費用感だけ知りたい方も、お気軽にご相談ください。
