【MYSQL】【高速化】「クォート」を付けると「5倍～10倍」以上の効果があるのは真実？【負荷対策】

現在プログラムの勉強をしている者です。

勉強目的で運用していたサイトが重くなってしまいましたので
MYSQLの処理で重くなっている部分を見直したり、ネットで高速化についての勉強をしていまして

一番良いのは処理の時間が長くなってしまう「like %%」を全文検索で
InnoDB のフルテキストインデックスを利用していく事なのですが
初心者には手順をの説明を読んでみても難しすぎたので
もっと手軽に出来る部分を探していた所、

とあるサイト様にて

クォートを入れたか入れないかだけの差ですが、これで5倍も10倍もパフォーマンスが違うのですから入れるべきです。

入れていない場合に、これは文章の切れ具合と、前後の文言を見ながらコンピュータ側で、これはフィールド名、これは検索語と判断しながら分けています。
バッククォートとクォートを入れることで、システム側の名前、入力した側の名前と分けることで処理が簡易化されるのです。

とありました。

参考サイト様：
パフォーマンス1000%UP!PHPでMySQLのDB処理を行うと重いときに行うパフォーマンス施策～基礎編～

これなら初心者の私にも出来ると思い早速試してみました。

【現状】
サーバの種類： MySQL
サーバのバージョン： 5.6.38 - MySQL Community Server (GPL)
PHP のバージョン: 5.6.31
phpMyAdmin
バージョン情報： 4.7.4

データ件数：約20万件

//シングルクォートが無い場合
mysql> select * from bbs where title LIKE '%悲報%' order by date_format( created, '%Y-%m-%d %H:%i' ) desc, ikioi desc;

//実行結果
1回目：4256 rows in set (0.24 sec)
2回目：4256 rows in set (0.24 sec)
3回目：4256 rows in set (0.21 sec)
4回目：4256 rows in set (0.23 sec)
5回目：4256 rows in set (0.21 sec)

//シングルクォートがある場合
mysql> select * from `bbs` where `title` LIKE '%悲報%' order by date_format( `created`, '%Y-%m-%d %H:%i' ) desc, `ikioi` desc;

//実行結果
1回目：4256 rows in set (0.23 sec)
2回目：4256 rows in set (0.24 sec)
3回目：4256 rows in set (0.24 sec)
4回目：4256 rows in set (0.27 sec)
5回目：4256 rows in set (0.24 sec)

シングルクォートがある場合と無い場合を比較した結果、
「5倍～10倍」早くなるどころか、「シングルクォートがない場合」の方が平均的に早いような
安定しているような結果になりました。

さらに

次によくあるケースが＊(アスタリスク)で全フィールドをよびだしているから重いというケースです。

プログラム内でテーブルを呼び出し出力するときに思わず楽なので
【*】アスタリスクで全フィールドを呼び出してしまいます。
レコード数が万を超えてくるあたりからパフォーマンスに差が出てきます。

このようにありましたが同じく試してみた所
「シングルクォート」の時と同じで
【*】を使った時と「カラム指定」の時での処理の速度が同じか
若干【＊】を使った時の方が早いという結果になりました。

これは私の環境に問題があり、
皆様の環境では正常に5倍～10倍近くの処理速度の向上が実感されているのでしょうか？

それともMySQL5.6.38になった事で
「シングルクォート」や「*」が無い場合でも処理速度が向上して
使っても使わなくてもどちらでも速度的には変わらなくなったのでしょうか？

プログラム関係の学校や職場にも残念ながら縁が無く
MYSQLに関する質問が出来ずに困っています。
お力をお貸し頂けると嬉しいです。

どうかよろしくお願いします。

行動規範の内容に同意します

回答1件

ベストアンサー

列名のシングルクオートについて

SQLのパース処理に掛かる時間は、実行時間に比べればほとんど無視できるので、パース結果が同じなら全体の処理時間はほとんど変わらないでしょう。
2. SELECTでの＊(アスタリスク)について
オプティマイザが適当な列を使用する様に最適化してくれますので検索時間にはあまり影響はないでしょう。しかし、検索結果を取得するときに不要な列が含まれていると当然その分遅くなります。
参考サイトではCOUNT(*)にもふれていますが、COUNT(列名)ではnullがカウントされないため注意が必要です。この場合、オプティマイザはCOUNT(適当なキー列)に読み替えてくれますので、下手に列名を指定するより速くなることもあります。

投稿2017/12/19 20:02