質問編集履歴
5
テーブルweb_list, tel_listのサンプルを追記しました。
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -59,3 +59,49 @@
|
|
|
59
59
|
|
|
60
60
|
|
|
61
61
|
master, web_list, tel_listのidを主キーにして速度が上がりました。しかしながら、まだかなり遅い印象で、まだ速くなる余地はないでしょうか。（tell_list, web_list共に2万件で1分ほど掛かります）
|
|
62
|
+
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
**web_list**
|
|
66
|
+
|
|
67
|
+
```web_list
|
|
68
|
+
|
|
69
|
+
id|name|inserted
|
|
70
|
+
|
|
71
|
+
11|bob |2016/09/01 12:00
|
|
72
|
+
|
|
73
|
+
12|mary|2016/09/01 13:00
|
|
74
|
+
|
|
75
|
+
15|mary|2016/09/05 10:00
|
|
76
|
+
|
|
77
|
+
16|bob |2016/09/06 15:00
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
|
|
82
|
+
|
|
83
|
+
**tel_list**
|
|
84
|
+
|
|
85
|
+
```tel_list
|
|
86
|
+
|
|
87
|
+
id|name|inserted
|
|
88
|
+
|
|
89
|
+
13|bob |2016/09/02 17:00
|
|
90
|
+
|
|
91
|
+
14|bob |2016/09/03 15:00
|
|
92
|
+
|
|
93
|
+
17|bob |2016/09/07 15:00
|
|
94
|
+
|
|
95
|
+
18|bob |2016/09/07 18:00
|
|
96
|
+
|
|
97
|
+
19|mary|2016/09/10 10:00
|
|
98
|
+
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
上記のようなイメージです。
|
|
102
|
+
|
|
103
|
+
この場合、INのサブクエリーで得られるID一覧は
|
|
104
|
+
|
|
105
|
+
11, 16
|
|
106
|
+
|
|
107
|
+
となります。
|
4
インデックスにより少し高速化されたことの追記
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -55,3 +55,7 @@
|
|
|
55
55
|
|
|
56
56
|
|
|
57
57
|
質問のために一部SQLを変更していましたが、自己検証を繰り返しているうちに端折っているINSERT文＋INの組み合わせが非常に時間を掛けていることが分かってきました。この点も踏まえてコメントをいただけるとありがたいです。
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
|
|
61
|
+
master, web_list, tel_listのidを主キーにして速度が上がりました。しかしながら、まだかなり遅い印象で、まだ速くなる余地はないでしょうか。（tell_list, web_list共に2万件で1分ほど掛かります）
|
3
masterにもインデックスはなかったため修正。update対象が0件でも異様に時間が掛かります
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
9
|
-
master
|
|
9
|
+
master, web_list, tel_listにはインデックスはありません。
|
|
10
10
|
|
|
11
11
|
idは自動採番、insertedは秒単位で全くバラバラです。nameは全体の2割ほどが複数回重複して含まれています。
|
|
12
12
|
|
2
質問のためselect \* masterとしましたが、update master〜でないと遅延の問題が起きないことが分かり修正しました。
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
「各レコードから見て後ろ3日以内で条件を満たすレコードが存在するもの」の一覧
|
|
1
|
+
「各レコードから見て後ろ3日以内で条件を満たすレコードが存在するもの」の結果一覧から高速にマスターをアップデートするSQL
|
test
CHANGED
|
@@ -12,13 +12,13 @@
|
|
|
12
12
|
|
|
13
13
|
|
|
14
14
|
|
|
15
|
-
ここで、web_listを上から順番に見ていって、あるレコード（例えばid=n）について【条件1】insertedが後ろ3日（259200秒）以内でかつ【条件2】nameが同一のレコードがあるもののidを抜き出して、master
|
|
15
|
+
ここで、web_listを上から順番に見ていって、あるレコード（例えばid=n）について【条件1】insertedが後ろ3日（259200秒）以内でかつ【条件2】nameが同一のレコードがあるもののidを抜き出して、masterに付き合わせてflagをアプデートしようとしています。
|
|
16
16
|
|
|
17
17
|
|
|
18
18
|
|
|
19
19
|
```SQL
|
|
20
20
|
|
|
21
|
-
|
|
21
|
+
update master set flag=1 where id in (
|
|
22
22
|
|
|
23
23
|
select id from web_list as wlst
|
|
24
24
|
|
|
@@ -51,3 +51,7 @@
|
|
|
51
51
|
|
|
52
52
|
|
|
53
53
|
nameが同一で、3日以内のレコードが1件以上存在する（0<）ということを条件にしてweb_listからidを列挙してきているのですが……、もっと高速にSQLを書き換えられないものでしょうか。
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
質問のために一部SQLを変更していましたが、自己検証を繰り返しているうちに端折っているINSERT文＋INの組み合わせが非常に時間を掛けていることが分かってきました。この点も踏まえてコメントをいただけるとありがたいです。
|
1
分かりやすくしようと前後3日かつbetweenを使う形にしましたが、自分を含んでしまうため実際に試したSQLと条件に則した条件とSQLに戻しました
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
「各レコードから見て
|
|
1
|
+
「各レコードから見て後ろ3日以内で条件を満たすレコードが存在するもの」の一覧を高速に列挙するSQL
|
test
CHANGED
|
@@ -12,7 +12,7 @@
|
|
|
12
12
|
|
|
13
13
|
|
|
14
14
|
|
|
15
|
-
ここで、web_listを上から順番に見ていって、あるレコード（例えばid=n）について【条件1】insertedが
|
|
15
|
+
ここで、web_listを上から順番に見ていって、あるレコード（例えばid=n）について【条件1】insertedが後ろ3日（259200秒）以内でかつ【条件2】nameが同一のレコードがあるもののidを抜き出して、masterから情報を**in**を使って列挙しようとしています。
|
|
16
16
|
|
|
17
17
|
|
|
18
18
|
|
|
@@ -30,11 +30,13 @@
|
|
|
30
30
|
|
|
31
31
|
wlst.name = tlst.name
|
|
32
32
|
|
|
33
|
-
|
|
33
|
+
and
|
|
34
34
|
|
|
35
|
-
|
|
35
|
+
wlst.inserted < tlst.inserted
|
|
36
36
|
|
|
37
|
+
and
|
|
38
|
+
|
|
37
|
-
|
|
39
|
+
tlst.inserted < wlst.inserted + 259200)
|
|
38
40
|
|
|
39
41
|
)
|
|
40
42
|
|