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