>　cpu:P3-1GHz-dual、mem:768MBなWindows2000マシン上の4.0.15-maxで試してみ
>ました。「create table tmp001 (NO int,MESSAGE varchar(50),DATE
>datetime);」なテーブルに対するレコード数と
>
>    SELECT a.* FROM tmp001 AS a LEFT JOIN tmp001 AS b ON a.NO=b.NO 
>      AND a.DATE < b.DATE WHERE b.NO IS NULL;
>
>のクエリの実行時間とを計測した結果が下の表です。ほぼレコード数の二乗で処
>理時間が増加している事が分かると思います。

>　今回の近藤さんのケースではテーブルのレコード数の明記が無いため、自己ジ
>ョインでも問題が無いレコード数なのかもしれません。ですが、自己ジョイン
>(に限らず、サブクエリでも自己結合的なものが存在するもの) は「論理的には
>正しいが、処理時間が現実的ではない」となるレコード数が、かなり小さな値と
>なる (場合がある、というか非常に多い)事に注意が必要です。

実行時間についての考察と補足をありがとうございます。

松枝さんへ

なるほど、自己ジョインに限らず普通のジョインでも「適切なインデックスが
なければ」直積のロー全件アクセスが起きてしまいますね。
使われるクエリーパターンに応じて適切なインデックスをつけるのは当たり前
だと思っていたのですが、それでは答えとしては足りないということですね。
すみませんでした。

近藤さんへ

今回の場合、自己ジョインの方法と、一時テーブルを使う方法では、その点に
気をつけて適切なインデックスを付けるなどの対処が要ります。その対処で、
松枝さんが示して下さっている最悪ケース（インデックスなしの状態）よりは
だいぶ速度が改善できます。
その上で、もう一つ実行時間に関係する因子があります。NOの重複度合いです。
アバウトに言うと、
・NOの重複が少ないとき
　GROUP BYのロー数が増えるので、結合文字列の方法と一時テーブルの方法が
　遅くなる傾向がある（GROUP BYの結果生成コストがロー数の二乗に近づく）
・NOの重複が多いとき
　LEFT JOINのロー数が増えるので、自己ジョインの方法は遅くなる傾向があ
　る（LEFT JOINの結果生成コストがロー数の二乗に近づく）
という感じになります。

それにしても、松枝さんが書いて下さっている結合文字列を使う方法はうまい
ですね。桁数をきちんと揃えるとかの考慮は要るものの、その条件を満たせば
有効な方法だと思います。

以上、ありがとうございました。

-- 
UNO Shintaro, 宇野 信太郎
mailto:uno@xxxxxxxxxx
http://www.venus.dti.ne.jp/~uno/