回答編集履歴
2
追記
answer
CHANGED
|
@@ -13,6 +13,11 @@
|
|
|
13
13
|
|
|
14
14
|
この二つが可能ならば上記を実施するだけでパフォーマンス的にかなり有利となるように思います。
|
|
15
15
|
|
|
16
|
+
特にMAX、MINなどの極値を得る集計関数は、
|
|
17
|
+
インデックスを定義しているとそれをそのまま利用してくれるため、
|
|
18
|
+
かなりコストを抑えることが可能です。
|
|
19
|
+
(インデックス自体が基本的にソート済のため)
|
|
20
|
+
|
|
16
21
|
以下は蛇足となります。
|
|
17
22
|
カラム数が多いテーブルならまだ良いのですが、
|
|
18
23
|
カラムはそこそこしかなくインデックスの数だけ増えてくると、
|
1
誤字修正
answer
CHANGED
|
@@ -1,15 +1,15 @@
|
|
|
1
1
|
実際に実行計画を見ないと確証はありませんが、
|
|
2
2
|
[こちらのQA](http://stackoverflow.com/questions/2158274/the-faster-of-two-sql-queries-sort-and-select-top-1-or-select-max)によるとMAXもTOPもパフォーマンス的差異はないか、
|
|
3
|
-
むしろインデックスが定義されていないケースでは実行速度が落ちる可能性もあります。
|
|
3
|
+
むしろインデックスが定義されていないケースではTOPの方が実行速度が落ちる可能性もあります。
|
|
4
4
|
[比較検証しているサイト](http://blogs.wankuma.com/kaya/archive/2006/10/17/41425.aspx)があったので参考までに。
|
|
5
5
|
|
|
6
6
|
|
|
7
|
-
ですので根本的に
|
|
7
|
+
ですので根本的に改善すべきはインデックスの設定となりそうです。
|
|
8
8
|
(質問でおっしゃっている７つ設定したインデックスの中に重複があればすみません・・・)
|
|
9
9
|
|
|
10
10
|
提示していただいているSQLのみに焦点を当てると、
|
|
11
|
-
-
|
|
11
|
+
- DATATYPE、PERIOD、POINTに対しての複合インデックスを付与
|
|
12
|
-
-
|
|
12
|
+
- 日付のカラムに対してもインデックスを付与
|
|
13
13
|
|
|
14
14
|
この二つが可能ならば上記を実施するだけでパフォーマンス的にかなり有利となるように思います。
|
|
15
15
|
|