回答編集履歴
9
追記
answer
CHANGED
|
@@ -36,22 +36,22 @@
|
|
|
36
36
|
もしかしたらPOSTする際に送受信するデータ容量が大きすぎて、
|
|
37
37
|
画面遷移までに時間がかかっているだけというお話かもしれませんね。
|
|
38
38
|
|
|
39
|
-
ます。
|
|
40
39
|
|
|
41
40
|
###追記２
|
|
42
41
|
更に余談を･･･
|
|
43
42
|
詳細画面表示時に発行するクエリですが、
|
|
44
43
|
WHERE句での条件指定、かつORDER BY句でも「year」を指定されてますね。
|
|
45
44
|
|
|
46
|
-
ちなみに**ORDER BY year
|
|
45
|
+
ちなみに**ORDER BY year DESC**を外したら検索結果が早くなるとかはありませんか？
|
|
47
46
|
もしそうであればこの場合の最適解は**yearカラムにインデックスを張ること**です。
|
|
48
47
|
|
|
49
48
|
ORDER BYでソートを行う処理は一時領域を使って処理を行ったりと、
|
|
50
49
|
予想以上に負荷の高い処理だったりします(一時領域があふれると悲惨)。
|
|
51
50
|
|
|
52
51
|
ですがORDER BY句に指定するカラムにインデックスを張ってあると、
|
|
53
|
-
**インデックスとして予めソートされたものを利用**するため処理が高速となります。
|
|
52
|
+
**インデックスとして予めソートされたものを利用祖**するため処理が高速となります。
|
|
54
|
-
また
|
|
55
|
-
|
|
53
|
+
(ソート順DESC指定のインデックスも作れたような記憶がある・・・)
|
|
56
54
|
|
|
55
|
+
また、WHERE条件の方でも**インデックスレンジスキャン(インデックス範囲検索)が利用**されるので一石二鳥となります。
|
|
56
|
+
|
|
57
57
|
ご参考までに・・・
|
8
表現訂正
answer
CHANGED
|
@@ -52,6 +52,6 @@
|
|
|
52
52
|
ですがORDER BY句に指定するカラムにインデックスを張ってあると、
|
|
53
53
|
**インデックスとして予めソートされたものを利用**するため処理が高速となります。
|
|
54
54
|
また
|
|
55
|
-
WHERE条件の方でも**インデックススキャンが利用**されるので一石二鳥となります。
|
|
55
|
+
WHERE条件の方でも**インデックスレンジスキャン(インデックス範囲検索)が利用**されるので一石二鳥となります。
|
|
56
56
|
|
|
57
57
|
ご参考までに・・・
|
7
誤字修正
answer
CHANGED
|
@@ -50,7 +50,7 @@
|
|
|
50
50
|
予想以上に負荷の高い処理だったりします(一時領域があふれると悲惨)。
|
|
51
51
|
|
|
52
52
|
ですがORDER BY句に指定するカラムにインデックスを張ってあると、
|
|
53
|
-
**インデックスとして予めソートされたものを
|
|
53
|
+
**インデックスとして予めソートされたものを利用**するため処理が高速となります。
|
|
54
54
|
また
|
|
55
55
|
WHERE条件の方でも**インデックススキャンが利用**されるので一石二鳥となります。
|
|
56
56
|
|
6
記載ミス修正
answer
CHANGED
|
@@ -41,7 +41,7 @@
|
|
|
41
41
|
###追記２
|
|
42
42
|
更に余談を･･･
|
|
43
43
|
詳細画面表示時に発行するクエリですが、
|
|
44
|
-
WHERE句での条件指定、かつORDER BY句でも指定されてますね。
|
|
44
|
+
WHERE句での条件指定、かつORDER BY句でも「year」を指定されてますね。
|
|
45
45
|
|
|
46
46
|
ちなみに**ORDER BY year ASC**を外したら検索結果が早くなるとかはありませんか？
|
|
47
47
|
もしそうであればこの場合の最適解は**yearカラムにインデックスを張ること**です。
|
|
@@ -51,5 +51,7 @@
|
|
|
51
51
|
|
|
52
52
|
ですがORDER BY句に指定するカラムにインデックスを張ってあると、
|
|
53
53
|
**インデックスとして予めソートされたものを基を利用**するため処理が高速となります。
|
|
54
|
+
また
|
|
55
|
+
WHERE条件の方でも**インデックススキャンが利用**されるので一石二鳥となります。
|
|
54
56
|
|
|
55
57
|
ご参考までに・・・
|
5
追記２
answer
CHANGED
|
@@ -18,7 +18,7 @@
|
|
|
18
18
|
曖昧検索を排除すると、
|
|
19
19
|
利便性が悪くなるのはもちろんなのて一般的にはPG難易度は上がりますがページングを採用するケースが多いと思われます。
|
|
20
20
|
|
|
21
|
-
###追記
|
|
21
|
+
###追記１
|
|
22
22
|
**ごめんなさい、一覧画面ではなく詳細画面の方が遅いのですね・・・**
|
|
23
23
|
上記の記載は戯言なので読み飛ばしてください。
|
|
24
24
|
(ながら作業は良くないですね・・・)
|
|
@@ -34,4 +34,22 @@
|
|
|
34
34
|
IE等のブラウザの**開発者ツール**というもので送受信などでかかった計測時間を調べることができます。
|
|
35
35
|
|
|
36
36
|
もしかしたらPOSTする際に送受信するデータ容量が大きすぎて、
|
|
37
|
-
画面遷移までに時間がかかっているだけというお話かもしれませんね。
|
|
37
|
+
画面遷移までに時間がかかっているだけというお話かもしれませんね。
|
|
38
|
+
|
|
39
|
+
ます。
|
|
40
|
+
|
|
41
|
+
###追記２
|
|
42
|
+
更に余談を･･･
|
|
43
|
+
詳細画面表示時に発行するクエリですが、
|
|
44
|
+
WHERE句での条件指定、かつORDER BY句でも指定されてますね。
|
|
45
|
+
|
|
46
|
+
ちなみに**ORDER BY year ASC**を外したら検索結果が早くなるとかはありませんか？
|
|
47
|
+
もしそうであればこの場合の最適解は**yearカラムにインデックスを張ること**です。
|
|
48
|
+
|
|
49
|
+
ORDER BYでソートを行う処理は一時領域を使って処理を行ったりと、
|
|
50
|
+
予想以上に負荷の高い処理だったりします(一時領域があふれると悲惨)。
|
|
51
|
+
|
|
52
|
+
ですがORDER BY句に指定するカラムにインデックスを張ってあると、
|
|
53
|
+
**インデックスとして予めソートされたものを基を利用**するため処理が高速となります。
|
|
54
|
+
|
|
55
|
+
ご参考までに・・・
|
4
ごめんなさい
answer
CHANGED
|
@@ -19,13 +19,19 @@
|
|
|
19
19
|
利便性が悪くなるのはもちろんなのて一般的にはPG難易度は上がりますがページングを採用するケースが多いと思われます。
|
|
20
20
|
|
|
21
21
|
###追記
|
|
22
|
-
ちなみにですが、
|
|
23
|
-
|
|
22
|
+
**ごめんなさい、一覧画面ではなく詳細画面の方が遅いのですね・・・**
|
|
24
|
-
|
|
23
|
+
上記の記載は戯言なので読み飛ばしてください。
|
|
24
|
+
(ながら作業は良くないですね・・・)
|
|
25
25
|
|
|
26
|
-
|
|
26
|
+
ただ1点気になったのが、
|
|
27
|
-
**最大表示件数に制限**を設ける手段があります。
|
|
28
|
-
ソート順固定だと件数を超えたデータはいつまでたっても表示出来ないので、
|
|
29
|
-
|
|
27
|
+
検索結果が表示されるまでが遅いというのは**本当にSQL側のレスポンスが悪い**のでしょうか？
|
|
30
28
|
|
|
29
|
+
試しに、詳細画面を開く際に発行されるであろうSQLを直接MySQLに投げても30秒とかかりますか？
|
|
30
|
+
もし直接実行して即検索結果が返ってくるのであれば、
|
|
31
|
+
それはDB側ではなくWeb側の構成の問題となります。
|
|
31
32
|
|
|
33
|
+
Web側でどの程度時間がかかるか詳しく知りたい場合でしたら、
|
|
34
|
+
IE等のブラウザの**開発者ツール**というもので送受信などでかかった計測時間を調べることができます。
|
|
35
|
+
|
|
36
|
+
もしかしたらPOSTする際に送受信するデータ容量が大きすぎて、
|
|
37
|
+
画面遷移までに時間がかかっているだけというお話かもしれませんね。
|
3
誤字修正
answer
CHANGED
|
@@ -23,9 +23,9 @@
|
|
|
23
23
|
万一DB側のデータ取得(DBが結果を返却するまで)はさほど遅くなかった場合は、
|
|
24
24
|
HTML表示時の処理がボトルネックとなっています。
|
|
25
25
|
|
|
26
|
-
そのケースだと上記で挙げたページング以外の策として
|
|
26
|
+
そのケースだと上記で挙げたページング以外の策として、
|
|
27
27
|
**最大表示件数に制限**を設ける手段があります。
|
|
28
28
|
ソート順固定だと件数を超えたデータはいつまでたっても表示出来ないので、
|
|
29
|
-
**ソート順はユーザが選択できるよう機能を追加**するなどのアレンジ
|
|
29
|
+
**ソート順はユーザが選択できるよう機能を追加**するなどのアレンジは必要となりますが。
|
|
30
30
|
|
|
31
31
|
|
2
追記
answer
CHANGED
|
@@ -15,6 +15,17 @@
|
|
|
15
15
|
- 原則前方一致のみの検索に制限する(前方一致はインデックスが利用されます)
|
|
16
16
|
- 前方一致と後方一致それぞれを設け、後方一致の場合は**関数インデックスを利用**する
|
|
17
17
|
- 前後曖昧検索が譲れない場合は**LIMITなどで抽出件数を絞りページングを採用**とする
|
|
18
|
+
曖昧検索を排除すると、
|
|
19
|
+
利便性が悪くなるのはもちろんなのて一般的にはPG難易度は上がりますがページングを採用するケースが多いと思われます。
|
|
18
20
|
|
|
21
|
+
###追記
|
|
19
|
-
|
|
22
|
+
ちなみにですが、
|
|
23
|
+
万一DB側のデータ取得(DBが結果を返却するまで)はさほど遅くなかった場合は、
|
|
24
|
+
HTML表示時の処理がボトルネックとなっています。
|
|
25
|
+
|
|
26
|
+
そのケースだと上記で挙げたページング以外の策として
|
|
27
|
+
**最大表示件数に制限**を設ける手段があります。
|
|
28
|
+
ソート順固定だと件数を超えたデータはいつまでたっても表示出来ないので、
|
|
20
|
-
|
|
29
|
+
**ソート順はユーザが選択できるよう機能を追加**するなどのアレンジが必要となります。
|
|
30
|
+
|
|
31
|
+
|
1
追記
answer
CHANGED
|
@@ -10,7 +10,8 @@
|
|
|
10
10
|
もしかしたらDBMS側で最適化されるかもしれませんが、
|
|
11
11
|
念のため検索条件の名前が省略された際は検索条件に加えないほうがいいでしょう。
|
|
12
12
|
|
|
13
|
+
さて本題ですが、パフォーマンス悪化の回避策ですが、
|
|
13
|
-
|
|
14
|
+
一般的には以下のような案があります。
|
|
14
15
|
- 原則前方一致のみの検索に制限する(前方一致はインデックスが利用されます)
|
|
15
16
|
- 前方一致と後方一致それぞれを設け、後方一致の場合は**関数インデックスを利用**する
|
|
16
17
|
- 前後曖昧検索が譲れない場合は**LIMITなどで抽出件数を絞りページングを採用**とする
|