質問編集履歴
8
解決したため
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -126,4 +126,14 @@
|
|
|
126
126
|
”存在しないURL”を指定すると、基本的に、INDEXが効きいて、1秒以内のレスポンスになりました。
|
|
127
127
|
ただし、"存在しないURL"が50文字以上となると、INDEXが効かず、300秒くらいのレスポンスになってしまいました。。
|
|
128
128
|
|
|
129
|
-
MySQL5.6.22のバグなんじゃないかと思い始めてます。。
|
|
129
|
+
MySQL5.6.22のバグなんじゃないかと思い始めてます。。
|
|
130
|
+
|
|
131
|
+
###追記６
|
|
132
|
+
AkiraPenguin 様の回答により、解決いたしました！
|
|
133
|
+
ありがとうございます！！！！！
|
|
134
|
+
|
|
135
|
+
なお、追記５の問題も、ちょうど50文字目が「_」となっておりました。
|
|
136
|
+
「_」を含むURLは300万件存在するため、「_」の後に存在しないURLを置いていても、
|
|
137
|
+
それはINDEXが効きません。。。当然ですね。。。
|
|
138
|
+
|
|
139
|
+
たくさんの閲覧・回答ありがとうございました！
|
7
追記
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -119,4 +119,11 @@
|
|
|
119
119
|
InnoDB化した場合、３００万の登録に６０分経っても終わらなかったため、INDEXが効くかどうかは分かりません。
|
|
120
120
|
別の仕様（毎秒１００件の削除・登録）が不可であるため、InnoDB化はできません。
|
|
121
121
|
（MyISAMであれば、３００万の登録に７分で終わります）
|
|
122
|
-
InnoDBは統計情報がきれいなはずなので、InnoDBであれば、確かに効く気はしています。
|
|
122
|
+
InnoDBは統計情報がきれいなはずなので、InnoDBであれば、確かに効く気はしています。
|
|
123
|
+
|
|
124
|
+
###追記５
|
|
125
|
+
INDEXが効いたSQLと効かないSQLがありましたので、情報共有いたします。
|
|
126
|
+
”存在しないURL”を指定すると、基本的に、INDEXが効きいて、1秒以内のレスポンスになりました。
|
|
127
|
+
ただし、"存在しないURL"が50文字以上となると、INDEXが効かず、300秒くらいのレスポンスになってしまいました。。
|
|
128
|
+
|
|
129
|
+
MySQL5.6.22のバグなんじゃないかと思い始めてます。。
|
6
追記
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -110,6 +110,13 @@
|
|
|
110
110
|
|
|
111
111
|
なお、上記２つのINDEXでは、URLのINDEXには届かないため、１件抽出する場合、即レスポンスにならないです。
|
|
112
112
|
|
|
113
|
+
INDEXさえ効けば、検索結果が１件の場合、即終わるハズなのですが、
|
|
114
|
+
実行計画の時点で効かない原因を知りたいです。。
|
|
113
115
|
|
|
116
|
+
###追記４
|
|
117
|
+
InnoDBについて
|
|
118
|
+
|
|
119
|
+
InnoDB化した場合、３００万の登録に６０分経っても終わらなかったため、INDEXが効くかどうかは分かりません。
|
|
120
|
+
別の仕様（毎秒１００件の削除・登録）が不可であるため、InnoDB化はできません。
|
|
114
|
-
|
|
121
|
+
（MyISAMであれば、３００万の登録に７分で終わります）
|
|
115
|
-
|
|
122
|
+
InnoDBは統計情報がきれいなはずなので、InnoDBであれば、確かに効く気はしています。
|
5
微修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -108,4 +108,8 @@
|
|
|
108
108
|
であれば、Limitが効くため、性能は良いですが、
|
|
109
109
|
検索結果が「１件」の場合、Limitの効果がないため、性能遅延が発生してしまいます。
|
|
110
110
|
|
|
111
|
-
なお、上記２つの
|
|
111
|
+
なお、上記２つのINDEXでは、URLのINDEXには届かないため、１件抽出する場合、即レスポンスにならないです。
|
|
112
|
+
|
|
113
|
+
|
|
114
|
+
INDEXさえ効けば、検索結果が１件の場合、即終わるハズなのですが、
|
|
115
|
+
実行計画の時点で効かない原因を知りたいです。。
|
4
追記３
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -95,4 +95,17 @@
|
|
|
95
95
|
|
|
96
96
|
###追記２
|
|
97
97
|
検索用URL（100文字等）を作ってINDEXを貼って検索するのは、個人的には良いのですが、
|
|
98
|
-
仕様決定者的にはNGでした。。
|
|
98
|
+
仕様決定者的にはNGでした。。
|
|
99
|
+
|
|
100
|
+
###追記３
|
|
101
|
+
index(col7,col1,url(200))の追加案については、
|
|
102
|
+
col7での絞込件数≒実際の絞込件数（urlによる絞り込みがほとんどない）
|
|
103
|
+
であれば、Limitが効くため、性能は良いですが、
|
|
104
|
+
検索結果が「１件」の場合、Limitの効果がないため、性能遅延が発生してしまいます。
|
|
105
|
+
|
|
106
|
+
index(col1,col7,url(200))の追加案については、
|
|
107
|
+
全体の件数≒col7での絞込件数≒実際の絞込件数（col7,urlによる絞り込みがほとんどない）
|
|
108
|
+
であれば、Limitが効くため、性能は良いですが、
|
|
109
|
+
検索結果が「１件」の場合、Limitの効果がないため、性能遅延が発生してしまいます。
|
|
110
|
+
|
|
111
|
+
なお、上記２つの時に、URLのINDEXには届かないため、効かないです。
|
3
仕様条件の追加
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -91,4 +91,8 @@
|
|
|
91
91
|
|
|
92
92
|
show table status like 'tb_test_data%';
|
|
93
93
|
にて、断片化は確認をしていて、0.6%程度の断片化率です。
|
|
94
|
-
（該当テーブルのURL以外の指定における性能劣化は見られていません。）
|
|
94
|
+
（該当テーブルのURL以外の指定における性能劣化は見られていません。）
|
|
95
|
+
|
|
96
|
+
###追記２
|
|
97
|
+
検索用URL（100文字等）を作ってINDEXを貼って検索するのは、個人的には良いのですが、
|
|
98
|
+
仕様決定者的にはNGでした。。
|
2
断片化とCHECK TABLEについて、追記済。
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -78,4 +78,17 @@
|
|
|
78
78
|
phpMyAdminのバージョンは4.5.1（ちょっと古い）
|
|
79
79
|
|
|
80
80
|
実行計画や速度が遅く感じると判断した際の動作環境は
|
|
81
|
-
phpMyAdmin上での実行結果になります。
|
|
81
|
+
phpMyAdmin上での実行結果になります。
|
|
82
|
+
|
|
83
|
+
|
|
84
|
+
###追記
|
|
85
|
+
check table tb_test_data;
|
|
86
|
+
を実行した場合、２時間経っても終わらないため、実施していません。
|
|
87
|
+
|
|
88
|
+
check table tb_test_data fast quick;
|
|
89
|
+
にて、テーブルの状態を確認していますが、
|
|
90
|
+
statusは「Table is already up to date」の状態で、問題ない認識です。
|
|
91
|
+
|
|
92
|
+
show table status like 'tb_test_data%';
|
|
93
|
+
にて、断片化は確認をしていて、0.6%程度の断片化率です。
|
|
94
|
+
（該当テーブルのURL以外の指定における性能劣化は見られていません。）
|
1
微修正
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -48,7 +48,7 @@
|
|
|
48
48
|
５：実行計画
|
|
49
49
|
```SQL
|
|
50
50
|
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
|
|
51
|
-
1 | SIMPLE | T1 | range |
|
|
51
|
+
1 | SIMPLE | T1 | range | IX_col1,IX_col2,IX_col3,IX_col5_col1,IX_col6,IX_col1_col5,IX_date,IX_url | IX_col1_col5 | 8 | NULL | 1157468 | Using index condition; Using where
|
|
52
52
|
```
|
|
53
53
|
※上記の実行計画は「http://abc.jp/xxx/xxxx/xxx%」の部分を68文字のURLを指定し、このURLだけで１件の表示になる値で実行計画を出しています。そのため、理想の実行計画としては、
|
|
54
54
|
refに「IX_url」が表示され、rows項目も1となる事を想定していました。
|