- PR -

SQLの性能

«前のページへ 1|2|3|4|5 次のページへ»
投稿者投稿内容
ハニワ祭り
大ベテラン
会議室デビュー日: 2005/11/15
投稿数: 115
投稿日時: 2006-07-07 00:01
なんとなくやりたいことはわかりました。
そういった場合、(条件とする値が7000個) をバッチクエリ等で
一旦別テーブルに出力してから、TableAと内部結合した方が
パフォーマンス的には有利かも知れません。

また＜TableAからの外部結合がいくつか＞ の結合条件に
インデックスが有るか無いかによってパフォーマンスは大きく変化すると
思います。
NEO
大ベテラン
会議室デビュー日: 2005/10/02
投稿数: 104
投稿日時: 2006-07-07 00:33
引用:

ハニワ祭りさんの書き込み (2006-07-07 00:01) より:
なんとなくやりたいことはわかりました。
そういった場合、(条件とする値が7000個) をバッチクエリ等で
一旦別テーブルに出力してから、TableAと内部結合した方が
パフォーマンス的には有利かも知れません。


バッチクエリとはいえ、結局問題のクエリは実行するわけですよね？
それなのに、性能が良くなるかも、という理由がよくわかりません。

引用:

また＜TableAからの外部結合がいくつか＞ の結合条件に
インデックスが有るか無いかによってパフォーマンスは大きく変化すると
思います。


TableAの方はインデックスを張っていない列で結合しているところもしますが、
相手側のテーブルの結合列は主キーです。
platini
大ベテラン
会議室デビュー日: 2002/12/03
投稿数: 193
投稿日時: 2006-07-07 00:44
引用:

バッチクエリとはいえ、結局問題のクエリは実行するわけですよね？
それなのに、性能が良くなるかも、という理由がよくわかりません。

問題のクエリは実行しないんだってば。
（少なくともinの部分は）
まずinの条件の7000個を列挙して別テーブルにしてExitsなどを
使ったり、inner joinしたほうが早いんじゃない？
とハニワ祭りさんは言いたいんだよ！

7000個もあれば当然、手作業で書くんじゃなくて
何らかの方法でプログラム的に書いているわけでしょ。
だったら、その過程でTEMPORARY　TABLEなどを使ってみたらというのが
ハニワ祭りさんのアドバイスだって。
本当に早くなるかはわからないが、やってみる価値はありだと思う。

最初から in のところに7000個も書いているという与件を
提示していないから、みんながあぁでもない、こうでもないという
議論に付き合わされたことにも気づいてくださいな。
KOX
大ベテラン
会議室デビュー日: 2004/08/23
投稿数: 142
投稿日時: 2006-07-07 09:25
Temporary tableを使用したほうが
おそらく速くなるでしょうね。

A.column1 in (条件とする値が7000個) は
--> A.column1 = '0' or A.column1 = '1' or A.column1 = '2' ....
と同じことなので、coloumn1がkeyであっても、おそらくindexは効かないでしょう。

Temporary tableを使用すれば
A.coloumn1 = B.coloum1　となり、
indexが効いてくると思われます。
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2006-07-07 12:02
in句に7000個?
それならクエリのコンパイルに時間がかかってもおかしくない。実行プランの確認を
しているのなら、コンパイル時間も表示されると思いますので、まずそこがボトル
ネックかどうか確認してください。

それから、そのin句に指定する値は、どこから引っ張ってくるものでしょうか。
もしもDBから引っ張ってくるものであれば、サブクエリにしたりすることはできない
のでしょうか。
platini
大ベテラン
会議室デビュー日: 2002/12/03
投稿数: 193
投稿日時: 2006-07-07 19:43
引用:

ちなみに、抽出元のテーブルには7000件のデータがあり、クエリ内で再帰結合を5つ行っています。

A.column1 in (条件とする値が7000個)

例えば数字の場合 between などに変換できませんか？ に対して
数字ですが、範囲指定はできない仕様なんですよね。



========================================================================
元テーブルが7000レコードで7000個のin と比較するって
すごく不思議なケース・・・だ。さてさて、

邪推してみました。根拠はありません。当てずっぽうです。

普通　in で比較する場合、その列はコード値やUniqueなものでしょう。
実際 A.column1のcolumn1は主キーだそうで・・・・。
で、column1が数字型だとすると、普通は整数でしょうね。
小数が主キーに使えないわけではないが、多分整数でしょう。

それで、連続していない数値というと・・・

もしや　
20040530
20040531
20040601
20040602

のように日付をYYYYMMDDで表現した数字じゃないんですか？

で、例えばそこから　平日のデータだけを抽出するというニーズだとか。

もし、column1がそのような日付的な要素の意味だとすれば、
そもそも in で　7000個書いて比較する処理を
何とかして早くする方法を考えようとするよりも、
抜本的に単純にSQLの見直しによる高速化が出来そうな気がする・・・・・・・・。

NEO
大ベテラン
会議室デビュー日: 2005/10/02
投稿数: 104
投稿日時: 2006-07-07 20:16
最初からクエリを書いていればよかったです。
すいませんでした。
まさかIN句のせいで遅くなっているとは思ってもみなかったので･･･。

運用としては、

1．あるクエリ(*1)でデータを検索して画面に表示。
2．表示されたデータのうち、CSVファイルに出力したいデータを選んで出力を実行。
名称など最新データを出力するために再度クエリを実行。

2．のクエリが問題のクエリです。
すなわち、1．で抽出した件数が2．のクエリの最大件数なのです。
1．のクエリは、抽出元テーブルに12000件あってもタイムアウトはしないのですが、
1．のクエリを2．で使うと、選んでいないデータも抽出されてしまうので、使えないんです。
これではバッチクエリも無理ですよね？

ハニワ祭り
大ベテラン
会議室デビュー日: 2005/11/15
投稿数: 115
投稿日時: 2006-07-07 20:46
やっぱりやりたいことはかなり想像どおりでした。

出力したいデータがユーザーによって選択されたら
それをバッチクエリで一時テーブルに出力して、
2．のクエリのINの部分を一時テーブルとの内部結合に置き換えては？

というのが、そもそもバッチクエリうんぬんの主旨です。


[ メッセージ編集済み 編集者: ハニワ祭り 編集日時 2006-07-07 20:49 ]
«前のページへ 1|2|3|4|5 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）