ソートは、非常にリソースを消費する処理です。かなりのCPU時間を必要としますが、問題の核心は、データベースが結果を 一次的にバッファしておかなくてはならないことです。ソート処理では、全ての入力を終えなければ、結果を出力することができません。ソート処理は、 パイプラインのようには実行できないのです。これは、データセットが大きい時に、問題になります。
インデックスされたデータはインデックスの順番に並んでいるという原則は、第1章1で既に説明しました。
そこから、インデックスはデータを既に並べ替えられた形で保存するためのものであるとも言えます。実際にインデックスは、order by句にインデックスの定義があるかのように並べ替えられます。
そのため、order by句を満たしつつソート処理を避けるために
インデックスが使えるというのは、自然な考え方と言えるでしょう。
皮肉な事に、INDEX RANGE SCANは大きなデータセットに対しては
非効率になってしまいます。後にテーブルアクセスが続く場合は特にその傾向があり、
ソート処理をしない事による節約分を食いつぶしてしまいます。明示的なソートをするFULL TABLE SCANの方が、
場合によっては高速かもしれません。色々な実行計画を評価し、最適なものを選択するのは、オプティマイザの役割です。
協力してください
この記事が気に入ったら、私の書いた本「SQLパフォーマンス詳解」や私によるトレーニングもきっと気にいるはず。
インデックスを使ってorder byを実行する良いところは、
ソート処理をしない事だけではなく、入力されたデータを全て処理する前に最初の結果を返してしまえる点も大きいのです。つまり、order byで
パイプライン化された処理が可能になるのです。第7章7, 「部分結果」で、効率的なページネーションのクエリを実装するために、
パイプライン化した実行をどのように使うかを説明しています。このように、パイプライン化されたorder byは非常に重要で、インデックスの強力さの3つ目に挙げられます。
この章では、order byをパイプライン化するために
どのようにインデックスを使うのかを説明していきます。そのためには、where句や、ASCあるいはDESC修飾語が
どのように作用するかに、特に注意を払う必要があります。そして、それらのテクニックをgroup by句に適用するところまでを扱います。
この説明が気に入れば、きっとこの本も 気に入るはず。
