インデックスを足すと遅くなるとき

日ごとの数字が入った表の鍵はひとつ、カウンターと日付の組である。コードの五か所は、この表に別の問いを立てる — 「このカウンターの時間変化」ではなく「これらの日の全カウンター」だ。トップページの一覧、ランキング、サイトマップ、90 日ぶんのグラフ、そして状態の数字。日付の列にインデックスがなければ、そのどれもが 114,113 行すべてを読む。

そのインデックスを足すと、一覧は十倍速くなる。足さなかった。そう決めた測定がこれである。

ひとつの問い合わせはずっと速くなった

一覧が求めるのは、今日アクセスのあったカウンターだ。日付にインデックスがなければ表を丸ごと走査する。あれば一つの日付を引いて 443 行を読む。61.5 ミリ秒が 6.1 ミリ秒になった。微妙な結果ではないし、これが測った唯一のものだったなら、インデックスは今ごろデータベースに入っている。

ふたつの問い合わせは遅くなった

サイトマップは十四日ぶんを求め、19 % 遅くなった。状態の数字は一年ぶんを求め、10 % 遅くなった。どちらの場合も、実行計画は主キーから新しいインデックスに乗り換え、そして悪いほうを選んだ。

ここが分かっておく値打ちのある部分だ。実行計画の欠陥ではないからである。二次索引で範囲を読むとは、索引の中で該当する行を見つけ、そのひとつひとつを表から取ってくること。細い帯ならお買い得だ。十三か月のうちの十四日となると、依然として多くの行を一件ずつ取ることになり、表をそのまま走査するほう — 物理的な順で読む、ディスクとキャッシュが好むやり方 — が勝つ。実行計画はそれを知らない。範囲と索引が見えたので、使う。

「このインデックスは一覧のときだけ使え」とは言えない。索引はその列に触れるすべての問い合わせに開かれていて、見積もりがそう告げる場所ならどこでも使われる。ひとつ足すのは、その表のすべての問い合わせへの変更であって、思い描いていたひとつへの変更ではない。

合わせると、何もない

五つ合わせて 555 ミリ秒が 524 ミリ秒になった。1.1 倍の改善、しかもこれらのページをどのみちキャッシュから返しているラズベリーパイでの話だ。スキーマを変える値打ちはない。

90 日グラフは 9 % 良くなったように見える。数に入れていないので、その理由を言っておく値打ちがある。どの問い合わせも三巡測った。インデックスなし、あり、そしてもう一度なし。二度目のインデックスなしが一度目の近くに着地しないなら、その差は機械のものであって変更のものではない。90 日グラフでは、インデックスなしの二巡が 13.8 % 食い違った — 主張したい効果より大きい。だからこの行は何も測っておらず、何もないものとして報告される。

どう測ったか、そしてなぜそれが効くのか

動いている表の上ではない。スクリプトは複製を作り、複製の上で作業し、最後にそれを捨てる。何が起きるか見るために本番の表へインデックスを足すのは、驚きひとつにつき一度しかできない。

問い合わせは本物で、コードから持ってきたもの、カウンター表との結合も含む。この試験の以前の版は簡略化した代役を使い、はるかに胸躍る答えを出した。二十倍速い、と。その簡略化した問い合わせは、どこも実行していない。

出ていたはずの数字

ふつうのやり方で測っていたら — 遅そうな問い合わせを取り、前と後で時間を計る — 答えは「十倍速い、入れよう」だっただろう。インデックスは入り、一覧は速くなり、サイトマップと状態ページは遅くなり、そして誰もその二つを結びつけない。誰もそちらを見ていなかったからだ。

これが一般的な形である。共有された土台への変更は、それを促した事例では評価できない。問うべきは「これは今見ているものの助けになるか」ではなく「ほかに何に触れ、それはどうなるか」だ。

うまくいくかもしれない版はある。両方の列を持ち、日付を先にした索引だ。そうすれば一覧は索引だけで答えられ、表へ戻らずに済む。広い範囲で実行計画を誘惑しないかもしれない。それは測っていないので、推奨ではない — 次に複製へ載せるものである。