回答編集履歴
2
追記
test
CHANGED
|
@@ -9,3 +9,8 @@
|
|
|
9
9
|
先ずは①を解消させることですが、質問の内容が端折られていて、実際のテーブル構造等も不明ですので、これ以上できるアドバイスはありません。
|
|
10
10
|
|
|
11
11
|
実行計画を取得してどこにネックがあるのか確認すると良いかと思います。
|
|
12
|
+
|
|
13
|
+
因みにですが、一時テーブルを作らなくても、元の表で以下のwindow関数で同じ結果になるのではないですか？
|
|
14
|
+
```SQL
|
|
15
|
+
DENSE_RANK() OVER(PARTITION BY COLUMN1, COLUMN2, COLUMN3, COLUMN4 ORDER BY SORT_COLUMN) AS SORT_NO
|
|
16
|
+
```
|
1
追記
test
CHANGED
|
@@ -2,6 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
1/4のデータの増減で1秒⇒20分ということで考えると、
|
|
4
4
|
①SQLでの問い合わせが掛け合わせの件数分となっている。
|
|
5
|
+
※「(COLUMN1,COLUMN2, COLUMN3,・・・)のパターン数の2乗）件数分、問合せしているのでは無いかと推測
|
|
5
6
|
②結合条件に最適なインデックスが無い
|
|
6
7
|
上記の理由により遅くなっているのだと思います。
|
|
7
8
|
|