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