ＫＫ＠ＩＢです

柳町さんの言われたことは、
「私がやりたかったのは、物理ソートまでやる必要のないこと」
という意味だと解釈しました。

物理ソートというのは、レコードを実際に
その順序に並べ直す処理です。

ソートの手法に、インデックスソートというのがあり、
インデックスを使った、「論理的な（ここでは、物理的に
は並べ替えをしない、という意味を含んでいます。）」
順序づけは、これに当たると考えて良いでしょう。

インデックスが無くても、レコードになにがしかの
一意的なマークをつけて、それで、並べ替えをする
ケースもあります。（下記のWHERE句があるORDER BYなど。）
そのときも、レコードを実際に並べ直すことは、
まずありません。

それで、物理ソートですが、その順序で
レコードをスムーズに読み出したいときに
物理ソートをしておいて、順（シーケンシャル）アクセス
したほうがトータルコストがかからない場合が
あります。

そういう時に使います。
そうでないときは、使わないでしょうね。

--------------------------------

以下、青山さんのコメントに対するコメントです。

> 検索するデータ数がある程度多い場合では、ランダムアクセスは
> 逆に効率が悪くなり、シーケンシャルアクセスの方が効率が良くなります。
> # これはまあ直感的にわかる話とは思いますが・・。

この話は、私は、もう少し説明が必要だと思います。
データが、飛び飛びにある状態で、いくつかデータを拾ってくるときは
一般には、ランダムアクセス、つまりインデックスを使った方が
早いでしょう。

なお、データ総数が数十程度だと、インデックス処理の
オーバーヘッドなどのせいで、シークエンシャル
アクセスの方が早い場合もあります。

>
> また、1個または数個のデータにアクセスしたい場合には常に
> ランダムアクセスの方が効率がよいのかというと、必ずしもそうではなく、
> 行数に比べてキー値の種類が少ない列(=カーディナリティが低い列)
> については、検索結果データの絶対数とディスク上の分布によって、
> どちらの方法が速いのかが変わってきます。

これは非常に重要な指摘ですね。
最速の検索は、データの内容によって変化します。
上記のような場合は、キーが意味をなさない状態です。
別のキーがない場合、同じキー値の中でシークエンシャルアクセスで
データを探す状態になりますから。

>
> また、全件検索する場合でも、Bツリーのリーフを順に読めばそのまま
> PRIMARY KEYの順になっているので、シーケンシャルアクセスをすれば
> PRIMARY KEYでソート済みデータが得られることになります。

PRIMARY KEYでデータを特定する場合は、ですね。

>
>
> このため、検索件数がある程度多い場合は、インデックスを使わずに
> シーケンシャルアクセス(FULL SCAN)する方が速かったりします。

これもほぼ上記と同じことのように読めますが、
もう少し説明が必要でしょう。

>
> このため、通常のインデックスを張った列データを検索キーにして
> 大量に検索をかける場合、ORDER BYなどを指定してしまうと
> インデックスを使って毎回ランダムアクセスせざるを得ないような
> 状況になってしまうので、上記の内容からすると、かなり重たい
> 処理になる可能性があることがわかると思います。

WHERE句が使われていて、データが複数選択された時、
ORDER BY がかかっている状態では、
その場での順序づけが必要でしょう。

WHERE句の指定条件にぴったり合ったインデックスが
ある場合は、それを使えば、再ソートは必要ないですが、
そういうものがない場合、順序づけする必要があるのではないでしょうか？

> 上記のことからわかると思いますが、
>
> ＫＫ＠ＩＢ さん:
>> order by の場合、データレコードを実際に並べ替えず、
>> そのレコードを指すインデックスをソートするのが一般的だと私は
>> 理解しています。
>
> とありますが、インデックスを使う場合は、最初からソートされているので
> 後からソートしたりはしません。

ここは、私の書き方が悪かったかもしれませんが、
「そのレコードを指すインデックス」とは、レコードのＩＤ（となっているもの）のことです。
「インデックスソート」の「インデックス」です。
青山さんのおっしゃっている「インデックス」は、そういうID的なものが、
並べられ終わった記録、ファイルのことですね。これもインデックスと呼ばれるので
話がややこしくなっていると思います。
それは、並べられているので、当然、並べ直しをもう一度やる必要はありません。

>
>
>> ところが、上述したように、特定の順番で、早く取り出す、などの目的で、
>> 実際にレコードをそういう順序で並べたい
>> ケースがあり、そういうときに、実際にレコードを
>> 様々な、その状況にあった手段で並べ直します。
>
> 文脈からすると「実際に」というのは物理的な並びを指しているのだと
> 思いますが、MySQLが勝手に全レコードを物理的に後から並べ替えたり
> することは決してありません。

マルチタスクでバックグランドでそういう処理をさせるようなシステムを
作れば別でしょうが、ＤＢＭＳが勝手に物理ソートをすることは
青山さんのおっしゃるとおり、まず無いでしょうね。

プログラマーが物理ソートをかけるという話です。
すみません。この話を書いていたときは、ＭｙＳＱＬのことを忘れていました。
一般的な話をしていました。

>
> MySQLの現在の機能では、物理的に並べ替えたい場合は、一旦データを
> ダンプしてからテーブルを削除し、再度テーブルを作り直す必要が
> あるようです。
> # Oracleとかだと運用しながらテーブル再構築する機能があったりします。

ＭｙＳＱＬがどうかは別とすると、（すみません、考えていなかったのです。）
ＤＢの機能としては、物理ソート機能があるのが普通ではないでしょうか？
そうでもないのでしょうかねぇ。