こんにちは。

UNO Shintaro <uno@xxxxxxxxxx>さんの
<200403070956.i279uGrK013930@xxxxxxxxxx>
"[mysql 08919] Re: DISTINCTオプションの動作について"


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

　インデックスを張る事により検索(SELECT)クエリの処理時間が短くなる可能性
はあります。別テーブルのINNER JOINの場合、インデックスの有無で処理時間は
天と地ですよね。

　インデックスを付けて処理時間の再計測をしてみました。テーブル定義は、
    create table tmp001 (NO int,MESSAGE varchar(50),DATE datetime,
        index IDX_NO_DATE (NO,DATE));
です。

    recs | no index | w/index
    -----+----------+---------
     100 |    0.02  |   0.02
    1000 |    1.14  |   0.69
    2000 |    4.59  |   2.73
    3000 |   10.31  |   6.24
    4000 |   18.34  |  11.09
    5000 |   28.78  |  17.58

　この表で見られる様に、処理時間が６割方と改善はされています。ですが、や
はりレコード数の二乗に比例の傾向は見て取れます。

　インデックスはもちろん万能ではありませんし、好ましくない副作用が無い訳
ではありませんし、特に今回の件に関しては「インデックスを張れば」に対して
はボクの意見は否定的です。挿入/更新/削除クエリの処理時間の増大は、(レコー
ド数が少ない場合やインデックスの実装によっては)軽視して構わない場合もあ
りますし、一概には言えません。Ｎの二乗な性質の方が大きな問題です。

　インデックスの副作用と言えば、錠さんの[mysql 08917]の場合、インデック
スの再構築が非常な重荷になっている事が８時間ものdeleteクエリの処理時間の
一因なのではと考えています。


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

　大昔に先輩から教えて貰いました。利用はかなり限定的ですが。



　　　　松枝知直　　　　<tomom@xxxxxxxxxx>
　　　　　　　　　　　　http://www.argus.ne.jp/~tomom/