MySQLのフェッチ時間の問題

Question

私はUbuntu x64、4Gb RAMの両方で、同じデータベース（コピー）を持つ2つの異なるMySQLサーバを持っています。両方とも、同じVMWareサーバーでホストされている仮想マシンです。

最初はMySQL 5.6.33-0ubuntu0.14.04.1-logを使用した旧バージョンのサーバで、新しいバージョンは5.7.17-0ubuntu0.16.04.1がインストールされています。

いくつかのSQLスクリプトのパフォーマンスを比較していますが、新しいサーバーのSQLでのフェッチ時間が大きいことに気づきました。考えられる原因を特定するのに役立つことができますか？

• 5.7エンジンは、SQLを効率的でない方法で分析しているのでしょうか？
• 多分、いくつかのMySQL設定を異なる方法で調整する必要がありますか？私はinnodb_buffer_pool_size = 2Gとinnodb_buffer_pool_instances = 2（古いサーバと同じ）だけを変更しました

アイデアはお考えですか？ Thx

Answer 1

あなたの問題は、バッファプールが割り当てられているが、まだデータがいっぱいではないと思われます。クエリを実行すると、RAMよりもはるかに遅いディスクからデータを取得する必要があります。これらのクエリを何度も実行すると、必要なデータはすでにバッファプールに格納されており、MySQLはこれを利用します。すでにバッファー・プールに入っているデータは、ディスクに触れることなく読み取ることができます。

バッファプールの容量を確認することができます。私のテストインスタンスからの例を示します（出力が長く、抜粋を表示しているので「...」をつけます）。

mysql> SHOW ENGINE INNODB STATUS\G 
... 
---------------------- 
BUFFER POOL AND MEMORY 
---------------------- 
... 
Buffer pool size 65528 
Free buffers  64173 
Database pages  1339 
... 

これらの数値はそれぞれ16KBの「ページ」です。あなたは64 * 1024ページ= 1GBが割り当てられていることがわかりますが、そのほとんどは無料です。つまり、データが空いています。私のバッファプールページの2％だけがデータを持っています。今すぐクエリを実行すると、データを読み込むためにディスクから読み込む必要があります。おそらく私のデータベースにもディスク上のデータはほとんどありませんし、完全にロードされていても私のバッファプールの2％しか占めていません。

とにかく、バッファー・プールのサイズよりも多くのデータがあると仮定すると、照会を実行するにつれて徐々にバッファー・プールがいっぱいになります。次に、「データベース・ページ」と「フリー・バッファー」の比率が時間の経過とともに変化することがわかります（同じものを参照しているので、ページとバッファーの両方がなぜそうであるのかわかりません）。後続のクエリはより速く実行する必要があります。