回答編集履歴
8
誤字修正
test
CHANGED
|
@@ -20,7 +20,7 @@
|
|
|
20
20
|
|
|
21
21
|
|
|
22
22
|
|
|
23
|
-
索引を追加して性能が改善する可能性があるのは、以下のようにnot exitsと相関複照会を用いたSQLに変更した場合です。こちらであればtableBの表アクセスが不要になるため、性能が向上するかもしれません。ただし、索引へのアクセスが新たにコストとして追加されるため、実測して比較する必要があります。
|
|
23
|
+
索引を追加して性能が改善する可能性があるのは、以下のようにnot exitsと相関複照会を用いたSQLに変更した場合です。こちらであればtableBの表アクセスが不要になるため、性能が向上するかもしれません。ただし、今度は索引へのアクセスが新たにコストとして追加されるため、実測して比較する必要があります。
|
|
24
24
|
|
|
25
25
|
|
|
26
26
|
|
|
@@ -30,7 +30,7 @@
|
|
|
30
30
|
|
|
31
31
|
from tableA tA
|
|
32
32
|
|
|
33
|
-
where not exits (
|
|
33
|
+
where not exists (
|
|
34
34
|
|
|
35
35
|
select tB.key1
|
|
36
36
|
|
7
誤字修正
test
CHANGED
|
@@ -36,9 +36,11 @@
|
|
|
36
36
|
|
|
37
37
|
from tableB tB
|
|
38
38
|
|
|
39
|
-
|
|
39
|
+
where
|
|
40
40
|
|
|
41
|
+
tA.key1 = tB.key1
|
|
42
|
+
|
|
41
|
-
and tA.key2 = tB.key2
|
|
43
|
+
and tA.key2 = tB.key2
|
|
42
44
|
|
|
43
45
|
)
|
|
44
46
|
|
6
誤字修正
test
CHANGED
|
@@ -16,9 +16,7 @@
|
|
|
16
16
|
|
|
17
17
|
--追記--
|
|
18
18
|
|
|
19
|
-
key1,key2に索引を追加しても、今のSQLでは結局HASH結合が選択され索引は使用されないと思われます。表の
|
|
19
|
+
key1,key2に索引を追加しても、今のSQLでは結局HASH結合が選択され索引は使用されないと思われます。表の大部分にアクセスするのであれば、1行ずつ索引を見るのはむしろ効率が良くないためです。
|
|
20
|
-
|
|
21
|
-
大部分にアクセスするのであれば、1行ずつ索引を見るのはむしろ効率が良くないためです。
|
|
22
20
|
|
|
23
21
|
|
|
24
22
|
|
|
@@ -34,7 +32,7 @@
|
|
|
34
32
|
|
|
35
33
|
where not exits (
|
|
36
34
|
|
|
37
|
-
select
|
|
35
|
+
select tB.key1
|
|
38
36
|
|
|
39
37
|
from tableB tB
|
|
40
38
|
|
5
追記
test
CHANGED
|
@@ -11,3 +11,37 @@
|
|
|
11
11
|
|
|
12
12
|
|
|
13
13
|
[ハッシュ結合](https://docs.oracle.com/cd/E49329_01/server.121/b71277/tgsql_join.htm#BABGBJFJ)
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
--追記--
|
|
18
|
+
|
|
19
|
+
key1,key2に索引を追加しても、今のSQLでは結局HASH結合が選択され索引は使用されないと思われます。表の
|
|
20
|
+
|
|
21
|
+
大部分にアクセスするのであれば、1行ずつ索引を見るのはむしろ効率が良くないためです。
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
索引を追加して性能が改善する可能性があるのは、以下のようにnot exitsと相関複照会を用いたSQLに変更した場合です。こちらであればtableBの表アクセスが不要になるため、性能が向上するかもしれません。ただし、索引へのアクセスが新たにコストとして追加されるため、実測して比較する必要があります。
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
```sql
|
|
30
|
+
|
|
31
|
+
select *
|
|
32
|
+
|
|
33
|
+
from tableA tA
|
|
34
|
+
|
|
35
|
+
where not exits (
|
|
36
|
+
|
|
37
|
+
select *
|
|
38
|
+
|
|
39
|
+
from tableB tB
|
|
40
|
+
|
|
41
|
+
tA.key1 = tB.key1
|
|
42
|
+
|
|
43
|
+
and tA.key2 = tB.key2
|
|
44
|
+
|
|
45
|
+
)
|
|
46
|
+
|
|
47
|
+
```
|
4
追記
test
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
100万件オーダーのテーブル同士の差分を求めるという要件で10分超を10分以下に抑えるチューニングというのは、改善の余地が小さく労力に対する見返りが少ないと思われます。しかもバッチ処理であればなおさらです。バッチライン上に他にチューニングの余地がないか分析した方が生産的でしょう。
|
|
1
|
+
100万件オーダーのテーブル同士の差分を求めるという要件で10分超を10分以下に抑えるチューニングというのは、改善の余地が小さく労力に対する見返りが少ないと思われます。しかもバッチ処理であればなおさらです。バッチライン上に他にチューニングの余地がないか分析した方が生産的と思いますが、何か事情があるのでしょうか。
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
3
追記
test
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
100万件オーダーのテーブル同士の差分を求めるという要件で
|
|
1
|
+
100万件オーダーのテーブル同士の差分を求めるという要件で10分超を10分以下に抑えるチューニングというのは、改善の余地が小さく労力に対する見返りが少ないと思われます。しかもバッチ処理であればなおさらです。バッチライン上に他にチューニングの余地がないか分析した方が生産的でしょう。
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
@@ -7,3 +7,7 @@
|
|
|
7
7
|
|
|
8
8
|
|
|
9
9
|
ただし、PGA上のHASHテーブルが溢れてしまうと一時表領域を使用するようになるのでパフォーマンスが低下します。実行計画のTempSpc項目を確認し、一時表領域が使用されていればPGAの拡張を検討してください。
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
|
|
13
|
+
[ハッシュ結合](https://docs.oracle.com/cd/E49329_01/server.121/b71277/tgsql_join.htm#BABGBJFJ)
|
2
修正
test
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
100万件オーダーのテーブル同士の差分を求めるという要件で、これを10分以下に抑えるチューニングというのは労力に対する見返りがかなり小さいと思われます。（しかもバッチ処理）
|
|
1
|
+
100万件オーダーのテーブル同士の差分を求めるという要件で、これを10分以下に抑えるチューニングというのは労力に対する見返りがかなり小さいと思われます。（しかもバッチ処理であればなおさら）
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
1
修正
test
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
100万件オーダーのテーブル
|
|
1
|
+
100万件オーダーのテーブル同士の差分を求めるという要件で、これを10分以下に抑えるチューニングというのは労力に対する見返りがかなり小さいと思われます。（しかもバッチ処理）
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|