回答編集履歴
8
推敲
answer
CHANGED
|
@@ -3,12 +3,7 @@
|
|
|
3
3
|
`(customer_id, voucher_date, voucher_no1, voucher_no2, ID, is_deleted)`
|
|
4
4
|
|
|
5
5
|
チューニングは適切にインデックスが使用される所から徐々に条件を追加するなどすると、分かりやすいですよ。
|
|
6
|
-
`voucher_no1, voucher_no2,ID`を共に含むインデックスが無いですね。
|
|
7
|
-
効率から考えると、以下の様な並びのインデックスじゃないかな。
|
|
8
|
-
`(customer_id, voucher_date, voucher_no1, voucher_no2, ID, is_deleted)`
|
|
9
6
|
|
|
10
|
-
チューニングは適切にインデックスが使用される所から徐々に条件を追加するなどすると、分かりやすいですよ。
|
|
11
|
-
|
|
12
7
|
追記
|
|
13
8
|
--
|
|
14
9
|
SQLは解決したとして、インデックスについて纏めると
|
7
推敲
answer
CHANGED
|
@@ -19,4 +19,4 @@
|
|
|
19
19
|
`is_deleted`と`id`についてはフィルター程度でしょうから、インデックスが使われない様なら、インデックスに含めるという事で。
|
|
20
20
|
|
|
21
21
|
現状とあまり違いは無いかもしれませんが、順序を変えるのは効果が出るかもしれません。
|
|
22
|
-
狙いとしては、抽出条件がインデックスのみ
|
|
22
|
+
狙いとしては、抽出条件がインデックスのみでの解決となる事。
|
6
追記
answer
CHANGED
|
@@ -12,10 +12,11 @@
|
|
|
12
12
|
追記
|
|
13
13
|
--
|
|
14
14
|
SQLは解決したとして、インデックスについて纏めると
|
|
15
|
-
**メイン用のインデックス(customer_id, voucher_no1, voucher_no2)**
|
|
15
|
+
**メイン用のインデックス(customer_id, voucher_date, voucher_no1, voucher_no2, is_deleted)**
|
|
16
16
|
**サブクエリー用のインデックス１(customer_id, voucher_date, voucher_no1)**
|
|
17
17
|
**サブクエリー用のインデックス２(customer_id, voucher_date, voucher_no2)**
|
|
18
18
|
になるかと。
|
|
19
19
|
`is_deleted`と`id`についてはフィルター程度でしょうから、インデックスが使われない様なら、インデックスに含めるという事で。
|
|
20
20
|
|
|
21
|
-
現状とあまり違いは無いかもしれませんが、順序を変えるのは効果が出るかもしれません。
|
|
21
|
+
現状とあまり違いは無いかもしれませんが、順序を変えるのは効果が出るかもしれません。
|
|
22
|
+
狙いとしては、抽出条件がインデックスのみ伝の解決となる事。
|
5
推敲
answer
CHANGED
|
@@ -18,4 +18,4 @@
|
|
|
18
18
|
になるかと。
|
|
19
19
|
`is_deleted`と`id`についてはフィルター程度でしょうから、インデックスが使われない様なら、インデックスに含めるという事で。
|
|
20
20
|
|
|
21
|
-
|
|
21
|
+
現状とあまり違いは無いかもしれませんが、順序を変えるのは効果が出るかもしれません。
|
4
修正
answer
CHANGED
|
@@ -18,4 +18,4 @@
|
|
|
18
18
|
になるかと。
|
|
19
19
|
`is_deleted`と`id`についてはフィルター程度でしょうから、インデックスが使われない様なら、インデックスに含めるという事で。
|
|
20
20
|
|
|
21
|
-
あ、現状
|
|
21
|
+
あ、現状とあまり違いは無いかもしれませんが、順序を変えるのは効果が出るかもしれません。
|
3
追記
answer
CHANGED
|
@@ -12,8 +12,10 @@
|
|
|
12
12
|
追記
|
|
13
13
|
--
|
|
14
14
|
SQLは解決したとして、インデックスについて纏めると
|
|
15
|
-
**メイン用のインデックス(customer_id,
|
|
15
|
+
**メイン用のインデックス(customer_id, voucher_no1, voucher_no2)**
|
|
16
16
|
**サブクエリー用のインデックス１(customer_id, voucher_date, voucher_no1)**
|
|
17
17
|
**サブクエリー用のインデックス２(customer_id, voucher_date, voucher_no2)**
|
|
18
18
|
になるかと。
|
|
19
|
-
`is_deleted`と`id`についてはフィルター程度でしょうから、インデックスが使われない様なら、インデックスに含めるという事で。
|
|
19
|
+
`is_deleted`と`id`についてはフィルター程度でしょうから、インデックスが使われない様なら、インデックスに含めるという事で。
|
|
20
|
+
|
|
21
|
+
あ、現状でほぼ問題ないですね。失礼しました。
|
2
追記
answer
CHANGED
|
@@ -2,4 +2,18 @@
|
|
|
2
2
|
効率から考えると、以下の様な並びのインデックスじゃないかな。
|
|
3
3
|
`(customer_id, voucher_date, voucher_no1, voucher_no2, ID, is_deleted)`
|
|
4
4
|
|
|
5
|
-
チューニングは適切にインデックスが使用される所から徐々に条件を追加するなどすると、分かりやすいですよ。
|
|
5
|
+
チューニングは適切にインデックスが使用される所から徐々に条件を追加するなどすると、分かりやすいですよ。
|
|
6
|
+
`voucher_no1, voucher_no2,ID`を共に含むインデックスが無いですね。
|
|
7
|
+
効率から考えると、以下の様な並びのインデックスじゃないかな。
|
|
8
|
+
`(customer_id, voucher_date, voucher_no1, voucher_no2, ID, is_deleted)`
|
|
9
|
+
|
|
10
|
+
チューニングは適切にインデックスが使用される所から徐々に条件を追加するなどすると、分かりやすいですよ。
|
|
11
|
+
|
|
12
|
+
追記
|
|
13
|
+
--
|
|
14
|
+
SQLは解決したとして、インデックスについて纏めると
|
|
15
|
+
**メイン用のインデックス(customer_id, voucher_date, voucher_no1, voucher_no2)**
|
|
16
|
+
**サブクエリー用のインデックス１(customer_id, voucher_date, voucher_no1)**
|
|
17
|
+
**サブクエリー用のインデックス２(customer_id, voucher_date, voucher_no2)**
|
|
18
|
+
になるかと。
|
|
19
|
+
`is_deleted`と`id`についてはフィルター程度でしょうから、インデックスが使われない様なら、インデックスに含めるという事で。
|
1
修正
answer
CHANGED
|
@@ -1,3 +1,5 @@
|
|
|
1
|
-
`voucher_no1, voucher_no2`を共に含むインデックスが無いですね。
|
|
1
|
+
`voucher_no1, voucher_no2,ID`を共に含むインデックスが無いですね。
|
|
2
2
|
効率から考えると、以下の様な並びのインデックスじゃないかな。
|
|
3
|
-
`(customer_id, voucher_date, voucher_no1, voucher_no2, is_deleted)`
|
|
3
|
+
`(customer_id, voucher_date, voucher_no1, voucher_no2, ID, is_deleted)`
|
|
4
|
+
|
|
5
|
+
チューニングは適切にインデックスが使用される所から徐々に条件を追加するなどすると、分かりやすいですよ。
|