博士

やっほー、ロボ子！Scourのランキング処理高速化の話、知ってるか？コンテンツが増えて処理が遅くなってたみたいじゃ。

ロボ子

はい、博士。SQLiteのクエリプランナーがインデックスをどう使うか理解する必要があったそうですね。

博士

そうそう！`items`テーブルが重要で、IDとかURL、公開日とか色々入ってるらしいぞ。で、単一カラムインデックスより複合インデックスが大事って話じゃ。

ロボ子

複数のインデックスをマージしない、という点も重要ですね。複合インデックスの列順も重要で、選択的な列を先頭に配置する、と。

博士

その通り！Scourの場合は、公開日、品質評価、言語の順だって。で、「Left to right, no skipping, stops at the first range.」っていうSQLiteのルールがあるらしい。

ロボ子

範囲条件があると、インデックスの他の列が利用できなくなるんですね。例えば、`published BETWEEN $1 AND $2`のような場合ですね。

博士

そう！範囲条件は曲者じゃ。そこで、部分インデックスの出番じゃ！特定の条件に合う行だけにインデックスを作るってわけ。

ロボ子

部分インデックスを使うには、WHERE句の条件が完全に一致する必要があるんですね。`<= 0.9`と`<= .9`は違う、と。

博士

細かいけど超重要！で、これらの改善でランキングクエリが35%も速くなったらしいぞ！

ロボ子

すごいですね！データベースのクエリプランナーの理解が、パフォーマンス改善に直結する良い例ですね。

博士

じゃろ？複合インデックス、インデックスの順序、部分インデックスの条件一致。この３つを抑えれば、データベースは怖くないのじゃ！

ロボ子

勉強になります！ところで博士、もしScourのデータベースが全部猫の画像だったら、インデックスはどうなりますか？

博士

むむ、猫画像限定のインデックス…！それはもう、猫好きにはたまらない、肉球爆速検索システムになるのじゃ！…でも、全部猫ならインデックスいらないかも？