回答編集履歴
7
追記3
test
CHANGED
|
@@ -151,3 +151,69 @@
|
|
|
151
151
|
あくまでもしかしたら言及があるかもという推測レベルです^^;
|
|
152
152
|
|
|
153
153
|
|
|
154
|
+
|
|
155
|
+
###追記３
|
|
156
|
+
|
|
157
|
+
2005年刊行ということで旧い書籍とはなりますが、
|
|
158
|
+
|
|
159
|
+
[Pro MySQL (The Expert's Voice in Open Source)](https://www.amazon.com/MySQL-Experts-Voice-Open-Source/dp/159059505X)の第2章「INDEX CONCEPT」のP66、
|
|
160
|
+
|
|
161
|
+
**「Query Structuring To Ensure Use Of Index」**の節にて、
|
|
162
|
+
|
|
163
|
+
インデックス列に関数を適用した例とその書き換えのサンプルが記載されています。
|
|
164
|
+
|
|
165
|
+
|
|
166
|
+
|
|
167
|
+
著者のjay pipes氏もMySQL界ではある程度名の知れた方とのことですが、
|
|
168
|
+
|
|
169
|
+
これを根拠とできるかは質問者様次第となると思います。
|
|
170
|
+
|
|
171
|
+
|
|
172
|
+
|
|
173
|
+
当方もMySQLのマニュアルをざっと見ましたが、
|
|
174
|
+
|
|
175
|
+
マニュアルにてオプティマイザについては、
|
|
176
|
+
|
|
177
|
+
> 注記
|
|
178
|
+
|
|
179
|
+
MySQL オプティマイザへの取り組みは継続中であるため、MySQL が実行する最適化のすべてをここで説明しているわけではありません。
|
|
180
|
+
|
|
181
|
+
|
|
182
|
+
|
|
183
|
+
との文面を残している以上は、
|
|
184
|
+
|
|
185
|
+
マニュアル内で最適化パターンを網羅してないのは間違いないので、
|
|
186
|
+
|
|
187
|
+
記載のない部分で100%の根拠を得るのは難しいと思われます。
|
|
188
|
+
|
|
189
|
+
|
|
190
|
+
|
|
191
|
+
- 実体験(実行計画を見た結果)
|
|
192
|
+
|
|
193
|
+
実行計画を調べて毎回インデックスが効かないことを確認
|
|
194
|
+
|
|
195
|
+
|
|
196
|
+
|
|
197
|
+
- データベース理論
|
|
198
|
+
|
|
199
|
+
他のDBMSに漏れずインデックス適用する仕組みは同様。
|
|
200
|
+
|
|
201
|
+
(というか他のDBMSで効かないけどうちでは効くよとかあったら普通にプッシュしそうな気がする)
|
|
202
|
+
|
|
203
|
+
|
|
204
|
+
|
|
205
|
+
- DBMS仕組み
|
|
206
|
+
|
|
207
|
+
そもそも関数インデックスという仕組みがなぜ必要なのか
|
|
208
|
+
|
|
209
|
+
|
|
210
|
+
|
|
211
|
+
|
|
212
|
+
|
|
213
|
+
これらを総合して100%に近づけるくらいしかできそうにないですね・・・
|
|
214
|
+
|
|
215
|
+
(公式に問い合わせて回答を得れるなら別なのですが)
|
|
216
|
+
|
|
217
|
+
|
|
218
|
+
|
|
219
|
+
|
6
追記2
test
CHANGED
|
@@ -118,7 +118,7 @@
|
|
|
118
118
|
|
|
119
119
|
|
|
120
120
|
|
|
121
|
-
###追記
|
|
121
|
+
###追記１
|
|
122
122
|
|
|
123
123
|
Generated Columnsは無しでしたのね、すみません^^;
|
|
124
124
|
|
|
@@ -131,3 +131,23 @@
|
|
|
131
131
|
(そのためORDER BYに指定する項目に対してインデックスを張りパフォーマンス改善を図る手段を取られることあり。MAX、MINに限ってはソートが終わってるものを使えば極値取るだけだからインデックス使う方が効率的)
|
|
132
132
|
|
|
133
133
|
|
|
134
|
+
|
|
135
|
+
###追記２
|
|
136
|
+
|
|
137
|
+
少し書籍を調べてみましたが、
|
|
138
|
+
|
|
139
|
+
ことMySQLに限定するなら以下の書籍が根拠足り得るものになるかもしれません。
|
|
140
|
+
|
|
141
|
+
[Effective MySQL Optimizing SQL Statements (Oracle Press)](https://www.amazon.com/Effective-MySQL-Optimizing-Statements-Oracle/dp/0071782796)
|
|
142
|
+
|
|
143
|
+
ただし邦訳版がないことと、僕自身が当該書籍を持っていませんので、
|
|
144
|
+
|
|
145
|
+
演算・関数適用時にインデックスが効かないという点をカバーしているかの判断できませんが・・・。
|
|
146
|
+
|
|
147
|
+
(この書籍の4章に当たる[サンプルコード](http://effectivemysql.com/book/optimizing-sql-statements/)に、
|
|
148
|
+
|
|
149
|
+
UPPER関数を利用した例が書かれてるので、
|
|
150
|
+
|
|
151
|
+
あくまでもしかしたら言及があるかもという推測レベルです^^;
|
|
152
|
+
|
|
153
|
+
|
5
誤字修正
test
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
hirohiroさんのあげてらっしゃるミック先生のサイトや著書**「達人に学ぶ SQL徹底指南書」**(WEBサイトの情報を再構成したものとはなりますが)、
|
|
4
4
|
|
|
5
|
-
またデータベース界の第一人者の一人ジョー・セルコ先生の**「プログラマのためのSQL」**(第4版はミック先生日本語
|
|
5
|
+
またデータベース界の第一人者の一人ジョー・セルコ先生の**「プログラマのためのSQL」**(第4版はミック先生日本語監訳)は参考となるかもしれません。
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
@@ -88,13 +88,13 @@
|
|
|
88
88
|
|
|
89
89
|
インデックス選択がより柔軟となるかもしれませんが、
|
|
90
90
|
|
|
91
|
-
個人的にはその辺りが便利になり過ぎることによる、インデックスの本質が
|
|
91
|
+
個人的にはその辺りが便利になり過ぎることによる、インデックスの本質が隠蔽されることは怖い気はします。
|
|
92
92
|
|
|
93
93
|
|
|
94
94
|
|
|
95
95
|
書き方を気にしなくなる面では非常に便利ですが、
|
|
96
96
|
|
|
97
|
-
それにより本質
|
|
97
|
+
それにより本質の理解が浅い開発者が増えると、
|
|
98
98
|
|
|
99
99
|
問題が発生しいざパフォーマンスチューニングが必要となった時に火を吹きそうで^^;
|
|
100
100
|
|
|
@@ -128,6 +128,6 @@
|
|
|
128
128
|
|
|
129
129
|
インデックス自体がソートされた状態で登録されてるためです。
|
|
130
130
|
|
|
131
|
-
(そのためORDER BYに指定する項目に対してインデックスを張りパフォーマンス改善を図る手段を取られることあり。MAX、MIN限ってはソートが終わってるものを使えば極値取るだけだからインデックス使う方が効率的)
|
|
131
|
+
(そのためORDER BYに指定する項目に対してインデックスを張りパフォーマンス改善を図る手段を取られることあり。MAX、MINに限ってはソートが終わってるものを使えば極値取るだけだからインデックス使う方が効率的)
|
|
132
132
|
|
|
133
133
|
|
4
誤字修正
test
CHANGED
|
@@ -80,11 +80,11 @@
|
|
|
80
80
|
|
|
81
81
|
**計算、または関数を噛ませて加工した後の値**というのは元々の値と違うのだからインデックスなんて効く方がおかしい話ではないでしょうか？
|
|
82
82
|
|
|
83
|
-
(確かに単純な四則計算とかだとど
|
|
83
|
+
(確かに単純な四則計算とかだとど行も同じ計算ルールを適用してるのだから、それくらい融通利かせろやとも思いますが^^;)
|
|
84
84
|
|
|
85
85
|
|
|
86
86
|
|
|
87
|
-
将来的にはこの辺はオプティマイザが
|
|
87
|
+
将来的にはこの辺はオプティマイザが賢くなることにより、
|
|
88
88
|
|
|
89
89
|
インデックス選択がより柔軟となるかもしれませんが、
|
|
90
90
|
|
3
追記
test
CHANGED
|
@@ -115,3 +115,19 @@
|
|
|
115
115
|
そのためここで定義した内容をそのまま左辺式に書いた場合はインデックスが適用されるようになります。
|
|
116
116
|
|
|
117
117
|
MySQLもVer5.7.6より[同等の機能が実装](https://yakst.com/ja/posts/2834)されたようです(**Generated Columns**)。
|
|
118
|
+
|
|
119
|
+
|
|
120
|
+
|
|
121
|
+
###追記
|
|
122
|
+
|
|
123
|
+
Generated Columnsは無しでしたのね、すみません^^;
|
|
124
|
+
|
|
125
|
+
|
|
126
|
+
|
|
127
|
+
後、集計関数のMAXとMINは例外的インデックスが効く理由はご存知とは思いますが、
|
|
128
|
+
|
|
129
|
+
インデックス自体がソートされた状態で登録されてるためです。
|
|
130
|
+
|
|
131
|
+
(そのためORDER BYに指定する項目に対してインデックスを張りパフォーマンス改善を図る手段を取られることあり。MAX、MIN限ってはソートが終わってるものを使えば極値取るだけだからインデックス使う方が効率的)
|
|
132
|
+
|
|
133
|
+
|
2
誤字修正
test
CHANGED
|
@@ -78,7 +78,7 @@
|
|
|
78
78
|
|
|
79
79
|
なのでそもそも論を言うと、
|
|
80
80
|
|
|
81
|
-
**計算、または関数を噛ませて加工した
|
|
81
|
+
**計算、または関数を噛ませて加工した後の値**というのは元々の値と違うのだからインデックスなんて効く方がおかしい話ではないでしょうか？
|
|
82
82
|
|
|
83
83
|
(確かに単純な四則計算とかだとどの列と同じ計算ルールを適用してるのだから、それくらい融通利かせろやとも思いますが^^;)
|
|
84
84
|
|
1
文面変更
test
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
次点の内容で言えば、
|
|
1
|
+
先ず次点の内容で言えば、
|
|
2
2
|
|
|
3
3
|
hirohiroさんのあげてらっしゃるミック先生のサイトや著書**「達人に学ぶ SQL徹底指南書」**(WEBサイトの情報を再構成したものとはなりますが)、
|
|
4
4
|
|
|
@@ -6,7 +6,9 @@
|
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
|
9
|
+
次にこれはMySQL公式とも関連してる話です。
|
|
10
|
+
|
|
9
|
-
|
|
11
|
+
DBMSが提供してくれている実行計画(実行プランとも言う)が信用できないと言われるとそこで試合終了となってしまうのですが、
|
|
10
12
|
|
|
11
13
|
結局はインデックスが使われてるのか、そうでないのかの判断の根拠は、
|
|
12
14
|
|
|
@@ -112,4 +114,4 @@
|
|
|
112
114
|
|
|
113
115
|
そのためここで定義した内容をそのまま左辺式に書いた場合はインデックスが適用されるようになります。
|
|
114
116
|
|
|
115
|
-
MySQLもVer5.7.6より[同等の機能が実装](https://yakst.com/ja/posts/2834)されたようです(Generated Columns)。
|
|
117
|
+
MySQLもVer5.7.6より[同等の機能が実装](https://yakst.com/ja/posts/2834)されたようです(**Generated Columns**)。
|