ソートとグルーピング


ソートは、非常にリソースを消費する処理です。 かなりのCPU時間を必要としますが、問題の核心は、データベースが結果を 一次的にバッファしておかなくてはならないことです。ソート処理では、 全ての入力を終えなければ、結果を出力することができません。ソート処理は、 パイプラインのようには実行できないのです。これは、データセットが大きい時に、 問題になります。

インデックスされたデータはインデックスの順番に並んでいるという原則は、 第1章で既に説明しました。 そこから、インデックスはデータを既に並べ替えられた形で保存するためのものである とも言えます。実際にインデックスは、order by句に インデックスの定義があるかのように並べ替えられます。 そのため、order by句を満たしつつソート処理を避けるために インデックスが使えるというのは、自然な考え方と言えるでしょう。

皮肉な事に、INDEX RANGE SCANは大きなデータセットに対しては 非効率になってしまいます。後にテーブルアクセスが続く場合は特にその傾向があり、 ソート処理をしない事による節約分を食いつぶしてしまいます。明示的なソートをするFULL TABLE SCANの方が、 場合によっては高速かもしれません。色々な実行計画を評価し、最適なものを選択するのは、 オプティマイザの役割です。

初心者からエキスパートまで役に立つ内容です。
特に駆け出しのエンジニアは持っておくといい

インデックスを使ってorder byを実行する良いところは、 ソート処理をしない事だけではなく、入力されたデータを全て処理する前に 最初の結果を返してしまえる点も大きいのです。つまり、order byパイプライン化された処理が可能になるのです。 第7章で、効率的なページネーションのクエリを実装するために、 パイプライン化した実行をどのように使うかを説明しています。 このように、パイプライン化されたorder byは非常に重要で、 インデックスの強力さの3つ目に挙げられます。

注記

Bツリーの走査が、 インデックスの強力さの1つ目。

クラスタ化が、 インデックスの強力さの2つ目。

パイプライン化されたorder byが、 インデックスの強力さの3つ目です。

この章では、order byをパイプライン化するために どのようにインデックスを使うのかを説明していきます。そのためには、 where句や、ASCあるいはDESC修飾語が どのように作用するかに、特に注意を払う必要があります。そして、それらのテクニックを group by句に適用するところまでを扱います。

この説明が気に入れば、きっと この本も 気に入るはず。

Photo of Markus Winand
Markus Winand氏は、開発者がSQLパフォーマンスを改善するお手伝いをしています。 彼は、SQL Performance Explainedの 著者でもあり、出張トレーニングhttp://winand.at/での リモート講義も 行っています。