1件を引く処理と、全件を数える処理は別物。図にした

• 1件を引く処理と、全件を数える処理は求めるものが違う
• 前者はインデックスが効き、後者は効きにくい
• 同じ表で両方やると、どちらかが遅くなる

「インデックスを足したのに集計が速くならない」。これは設定の問題ではなく、処理の性質が違うためだ。図にした。

触る行数が決定的に違う

この違いが、最適な形をすべて決める。

1件を引く処理

注文番号から注文を1件引く、会員IDから会員情報を引く、記事IDから本文を引く。日々の処理のほとんどがこれにあたる。

• 1回で触る行は少ない
• その代わり回数がとても多い
• 求めるのは1回あたりの応答の速さ

ここではインデックスが効く。全体から目的の1行を絞り込む作業そのものだからだ。

全件を数える処理

月別の売上を出す、カテゴリごとの本数を数える、1年分の傾向を見る。答えを出すために、ほぼ全部を読む必要がある。

• 1回で触る行が多い
• 回数は少ない
• 求めるのは集計が終わるまでの速さ

ここでインデックスは効きにくい

MySQLの公式文書にそのまま書かれている。

インデックスは、小さなテーブルや、ほとんどの行を処理する集計系の問い合わせでは重要度が下がる。問い合わせがほとんどの行にアクセスする必要がある場合、順に読むほうがインデックスを辿るより速い。

理由は単純で、インデックスは「どこを読むか」を特定する仕組みだからだ。全部読むと決まっているなら、特定する手間が増えるだけになる。

同じ表で両方やると困る

1つの表に対して、日々の処理と集計を同時に走らせると衝突する。

• 集計が重い — 全行を読む処理が走っているあいだ、日々の処理の応答が落ちる
• インデックスが増える — 集計用にも足すと、書き込みのたびに更新する対象が増える
• ロックが当たる — 読んでいる最中の更新を待たせることがある

よく取られる分け方

1. 時間をずらす — 集計は利用の少ない時間に回す。もっとも手軽
2. 結果を保存する — 毎回集計せず、集計済みの表を別に持つ
3. 読む先を分ける — 集計は複製したほうを読む

小規模なら1番と2番で足りることが多い。毎回集計し直す必要があるかを先に疑う。昨日までの数字が変わらないなら、保存しておけばよい。

見分け方

自分が書いた問い合わせがどちらなのかは、2つ見れば分かる。

1. 結果が何行返るか — 1行なら前者、1行でも集計した結果の1行なら後者
2. 答えを出すのに何行読む必要があるか — ここが本質

間違えやすいのは件数を数える処理だ。返るのは1行だが、数えるためには全部を見ている。結果の行数ではなく、読む行数で判断する。

WordPressで起きること

記事の一覧に「全体で何件」と出す、カテゴリごとの本数を出す、といった処理が集計にあたる。記事が増えるほど重くなる。

このサイトでも、分野ごとの最新記事を出す処理を1回の問い合わせでまとめて取る形に書き換えた。分野ごとに個別に問い合わせると、分野の数だけ集計が走ることになる。

どこが遅いのかを先に測る手順はサイトが遅い原因を、推測ではなく測って特定したに書いた。

まとめ

• 1件を引く処理は触る行が少なく、回数が多い。応答の速さを求める
• 全件を数える処理は触る行が多く、回数が少ない。集計の速さを求める
• 公式に「ほとんどの行にアクセスするなら、順に読むほうが速い」と明記されている
• 同じ表で両方やると、互いに足を引っ張る
• 分け方は、時間をずらす／結果を保存する／読む先を分ける
• まず毎回集計し直す必要があるかを疑う

出典

• MySQL 8.4 Reference Manual「How MySQL Uses Indexes」（集計系の問い合わせでインデックスの重要度が下がること）

図は本記事のために作成したもの。本記事は2026年10月13日時点の内容に基づく。