こんばんは、兵頭です。

池田様
> column_A_6とcolumn_A_9にインデックスは付与されていますか？
両方ともインデックスは付与されていません。
別のcodeのカラムに付与しています。
column_A_6とcolumn_A_9にインデックスは付与すべきなのでしょうか？

先にYuGoさんに教えてもらいました下記URLより「ORDER BY」でソートをしていると
テンポラリファイルを使用するとありました。
http://dev.mysql.com/doc/refman/4.1/ja/temporary-files.html
試しに「ORDER BY]を外してみて実行してみたところ、TEMPフォルダには
ファイルは作成されませんでした。
実行時間も格段に短縮されました。（１０００ｓ以上→３００ｓ以下）

そこで、ご存知でしたらご教授お願いしたいのですが、今回のクエリで
「ORDER BY」を使用した理由は、３００万以上のレコード全てを抽出するのに
1度のクエリで実行した場合には変数に格納できなくなってしまうので
３０万件ごとに分割にしています。
そこで、Limitで区切ったのはいいのですが、３００００１件からの重複しない順番はで
続きのデータが抽出できるか不明だった為、「ORDER　BY 」を使用してソートしてから 

３０万件ごと抽出するという処理をしていました。
ここで「ORDER BY」を指定しなかった場合、重複しないで抽出はされるのでしょか？
抽出される順番は特に問いません。

宜しくお願いします。

兵頭

----- Original Message ----- 
From: "Tetsuro IKEDA" <te.ikeda@xxxxxxxxxx>
To: <ml@xxxxxxxxxx>
Sent: Tuesday, April 24, 2007 6:32 PM
Subject: [mysql 13896] Re: ＴＥＭＰフォルダ内のファイルサイズ


> 池田です。
>
> Explainによると、
>
> (1) TABLE_Aからインデックスcodeをフルスキャンしつつ200万行超の
> 　　レコードをcolumn_A_9、column_A_6の値による絞込みをしつつ抽出。
> (2) 抽出結果に対して、TABLE_Bと結合。
> (3) さらにTABLE_Cと結合。
> (4) さらにTABLE_Dと結合。
>
> という感じで処理しているようです。
>
> (1)の処理が重いですね。
>
> column_A_6とcolumn_A_9にインデックスは付与されていますか？
>
> MySQL 5.0以上であればindex_merge機能が入っていますので、
> index_mergeによって読み取り行数を大幅に減らすことが可能
> かもしれません。
>
> MySQL 4.1以下の場合には、マルチカラムインデックスなどで
> 逃げられないかどうかを検討してみましょう。
>
> とはいえ、、、、
>
> 1.5GBのテーブルに30GBの一時テーブル、というのは大きすぎな気がします。
> テーブルが壊れていたりはしませんか？
> CHECK TABLE、REPAIR TABLEなどで確認してみましょう。
>
>>
>> 池田様
>> >ちなみにどんなクエリなんでしょうか？
>> >EXPLAIN付きで示していただきたく。
>> SQL文をそのままはまずいので、テーブル、カラム名を変えています。
>> TABLE_Aが基本となっており、ＴＡＢＬＥ＿Ｂをの値を参照しています。
>> TABLE_DはTABLE_Cを参照して、TABLE_Dを参照しています。
>> 上記の内容に加え指定した月から現在までのデータを抽出しています。
>> 30万件単位で行っています。
>>
>> SELECT
>> TABLE_A.id,TABLE_A.code,
>> TABLE_A.column_A_1,TABLE_A.column_A_2,TABLE_A.column_A_3,
>> TABLE_A.column_A_4,TABLE_A.column_A_5,TABLE_B.column_B_1,
>> TABLE_A.column_A_7,TABLE_A.column_A_8,TABLE_A.column_A_9,
>> TABLE_D.column_C_10,TABLE_A.column_A_11,TABLE_A.column_A_12,
>> TABLE_A.column_A_13,TABLE_A.column_A_14
>> FROM
>> TABLE_A,TABLE_B,TABLE_C,TABLE_D
>> WHERE
>> TABLE_A.column_A_6 = TABLE_B.id AND
>> TABLE_A.column_A_9 = '0' AND
>> TABLE_A.code = TABLE_D.code AND
>> TABLE_C.column_C_1 = TABLE_D.id AND
>> TABLE_A.column_A_6 > '2006-12-00'
>> ORDER BY
>> TABLE_A.code
>> LIMIT 0,300000
>>
>>
>> ＥＸＰＬＡＩＮ文
>> |table        |  type   |  possible_keys       |  key          |  key_len 
>> |
>> ref                            |  rows        |  Extra         |
>> |-------------------------------------------------------------------------------------------------------------------
>> |TABLE_A  |  index  |  code                   |  code        |  20 
>> |
>> NULL                          |  2458926  |  Using where   |
>> |TABLE_B  |  eq_ref |  PRIMARY            |  PRIMARY  |  4        |
>> TABLE_A.column_A_6       |  1          |                |
>> |TABLE_C  |  ref   　 |  code,column_C_1  |  code         |  20       |
>> TABLE_A.code              |  1          |                |
>> |TABLE_D  |  eq_ref |  PRIMARY            |  PRIMARY  |  4        |
>> TABLE_C.column_C_1       |  1          |                |
>> --------------------------------------------------------------------------------------------------------------------
>> 以上です。
>> 宜しくお願いします。
>>
>> 兵頭
>>
>
> -----------------------------------------
> Tetsuro IKEDA, te.ikeda at jpta.scs.co.jp
> Kachidoki, Tokyo, Jpan
> http://www.scs.co.jp/mysql/
> -----------------------------------------
>
>
>
>