1

MySQLクエリの最適化に取り組んでいますが、奇妙な問題が発生しています。mysqldumpライブの本番データベースを使用することはないので、ダンプを作成し、追加のオプションを使用せずにローカルマシンのデータベースにインポートします。

本番データベースとローカル仮想マシンのmysqlのバージョンはほぼ同じです。

本番環境：mysql Ver 14.14 Distrib 5.1.61、readline 6.2を使用したdebian-linux-gnu（x86_64）用

仮想マシン：mysql Ver 14.14 Distrib 5.1.63、readline 6.2を使用したdebian-linux-gnu（x86_64）用

この1つのクエリは非常に複雑で、本番環境では約4〜5秒かかりますが、VMでは1秒未満かかります。私が考えることができる唯一のことは、クエリがすぐに実行されないようにする本番データベースのロックがあり、クエリはロックを待機する必要があるということです。

各EXTENDED EXPLAINデータベースに対してクエリを実行する場合はほぼ同じですが、わずかな違いがいくつかあります。

SQL_NO_CACHEクエリがキャッシュにヒットしないようにするために、クエリの前に使用しています。

だから私の質問は：

  1. EXTENDED EXPLAIN本番データベースのコピーを使用していて、mysqlのバージョンが同じである場合、何が少しでも異なる原因になる可能性がありますか？
  2. 同じクエリが本番データベースでより長くかかると私が考えていない理由はありますか？
4

1 に答える 1

3

この実行時間に影響を与える可能性のあるものがいくつかあります。

実稼働システムでのロードはどのようになっていますか？IOのヘッドルームはどれくらいありますか？システムが他のクエリの実行や大量のIOの実行でビジー状態の場合、クエリのパフォーマンスは大幅に低下します。

一般にSHOW PROCESSLIST、現在実行されているものを識別し、プログラムがiotopどのくらいのIOが実行されているかを確認するために使用できます。

仮想マシンはSSDで実行されていますか？SSDを備えたミッドレンジの開発マシンでさえ、ランダムアクセスに大きく依存しているものであれば、ほぼすべてのHDベースのデータベースサーバーを吹き飛ばします。

OPTIMIZE TABLE実動システムを試したことはありますか？復元を実行すると、テーブルは常に自動的に最適化されます。INSERT稼働中のシステムでは、テーブルはあなたとDELETE行としてゆっくりと劣化します。

両方が同じストレージエンジンを使用していることを確認してください。MyISAMは多くの場合InnoDBよりも高速ですが、重要なデータの本番環境で使用するのは安全ではありません。SHOW TABLE STATUS各テーブルに使用されているエンジンを確認してください。デフォルトが異なる場合があります。

また、/etc/my.cnfそれに応じて調整されていることを確認してください。MySQLのデフォルト設定はひどいです。本当にInnoDBバッファーにもっと多くのメモリーを割り当てる必要があります。そうしないと、パフォーマンスがひどくなります。

于 2013-01-28T18:13:53.973 に答える