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