回答編集履歴
1
修正
answer
CHANGED
|
@@ -1,8 +1,6 @@
|
|
|
1
|
-
EXPLAINすればボトルネックが判明しそうですが、これくらいならsqlを分けて検証してみても良いと思います。
|
|
2
|
-
|
|
3
1
|
**updateが遅いとしたら**
|
|
4
|
-
単純に件数が膨大過ぎる場合でしょう「update master set flag=1 where
|
|
2
|
+
masterのレコード数が膨大でidにindexが無いためか、単純に件数が膨大過ぎる場合でしょう「update master set flag=1 where ....」ですからね。基本的にwhere句以前には改善点がありません。
|
|
5
|
-
|
|
3
|
+
物理的に更新行が多すぎるなら改善は難しいです。PCスペックを上げるとか？
|
|
6
4
|
|
|
7
5
|
**目的のIDを抽出するsql**
|
|
8
6
|
多分次のように成ると思いますが、これは早いでしょうか？
|
|
@@ -14,11 +12,9 @@
|
|
|
14
12
|
AND t.inserted <= w.inserted + INTERVAL 3 DAY
|
|
15
13
|
GROUP BY w.id
|
|
16
14
|
```
|
|
17
|
-
これが早いなら、in句が遅いか、masterのレコード数が膨大な上indexが適当でないかのどちらかが原因かと思います。EXISTSに変更してみるか、masterのidにindex（プライマリキーにしているなら不要)を作成してみると良いかも知れません。
|
|
15
|
+
これが早いなら、in句が遅いか、冒頭で書いたようにmasterのレコード数が膨大な上indexが適当でないかのどちらかが原因かと思います。EXISTSに変更してみるか、masterのidにindex（プライマリキーにしているなら不要)を作成してみると良いかも知れません。
|
|
18
16
|
|
|
19
17
|
逆にこれが遅いならweb_listかtell_listのレコード数が膨大でindexが適切でないためだと思います。
|
|
20
18
|
nameに重複が少ないならname、またinsertedへのindexの作成を検討する必要があるかも知れません。
|
|
21
19
|
|
|
22
20
|
in句やdistinctはmysql5.1 以前だとやたら遅くなるケースがあったように思います。ただ特定のケースでindexが使えて無いことに起因してたように思うので、そもそもindexを作成していないなら関係無いと思いますし、5.4以降だとそんなことも無い気がします...
|
|
23
|
-
|
|
24
|
-
後は可能性は低いですが、動作させているマシンがいっぱいいっぱいでスワップを繰り返してる可能性も一応。
|