MySQLサーバーをテストサーバーと本番サーバーの2つの異なるマシンにインストールしました。どちらもWindowsであり、ウェブアプリケーションで使用されます。

問題は、いくつかのクエリを実行すると、2つのマシン間でパフォーマンスが大幅に異なることです（本番サーバーの方が低速です）。両方のサーバーのMySQLバージョンは同じです。構成ファイルも同じです（唯一の違いは、データのパスと、運用サーバーがエラー以外のログを記録しないことです）。私が話しているパフォーマンスの違いは3桁または4桁大きくなっています（たとえば、テストサーバーでのクエリは0.2秒で実行されますが、運用サーバーでは84秒で実行されます）。

問題のクエリは、 "WHERE [...] IN [...]"を含む句を多用しています。これは、通常非常に遅く、JOINに置き換える必要があることを理解しています。ただし、使用しているMySQLのバージョンは5.6.19であり、これらのクエリは自動的に最適化されます。そのため、テストサーバーではクエリが高速に実行されます（変更できないプログラムの一部であるため、手動で最適化することはできません）とにかく）。

先ほど述べたように、MySQLのインストールと構成は同じであるため、問題がどこにあるのかはまったくわかりません。一方では、プログラムとDBが同じであるため、なんらかの構成上の問題である必要があると思いますが、一方で、構成が同一であるため、これは意味がありません。

サーバー上のデータ：
テストサーバー：

• Intel Core 2 Quad Q9400 @ 2.66GHz
• 8GB RAM
• Windows Server 2008 R2スタンダード

本番サーバー：

• Intel Xeon E5530 @ 2.40GHz
• 5GB RAM
• Windows Server 2012 R2スタンダード

編集：重要なことを言うのを忘れていました。「問題の」クエリとは別に「WHERE ... IN」句を使用するクエリが実行されています。これらは両方のマシンで高速に実行され、MySQLによって正しく最適化されていることを示唆しています。他のクエリが最適化されていないときに最適化されているクエリがあるのは不思議です。これが実際の問題であるかどうかは不明です。

編集＃2：両方のサーバーの構成ファイルは次のとおりです：http : //pastebin.ca/2834906

編集＃3：遅いクエリの1つ のEXPLAINは次のとおりです。https：//mariadb.org/ea/v36zj EXPLAINは、テストと製品の両方でまったく同じです。クエリ自体はこちらです：http : //pastebin.com/VXgBxXmtこれはオートフォーマッタでフォーマットされているため、あまり明確ではありません。ご覧のとおり、は非常に長く複雑です。これは手動で生成されたものではなく、いくつかの機能を備えた標準SQLの方言を使用するソフトウェアによってさらに自動的に生成されます。

また、詳細情報：本番サーバーのデータを減らし、使用されないDBの古いデータのほとんどを削除することで、一時的に問題にパッチを適用しました。もちろん古いデータも必要なので、これは解決策ではありません。将来的には問題になるでしょう。DBはそれほど大きくありません。完全なDBは1308MBで、現在生産中の縮小バージョンは332MBです。

更新：解決しましたか？

私は問題を解決したと思います。本番サーバーが実際に使用されているため、まだテストしていませんが、考えられる問題は、182Mに設定されたパラメーター "innodb_buffer_pool_size"でした。実際には、構成ファイルの行は次を示しています：innodb_buffer_pool_size = 321これはユニットプレフィックスがないため誤りであり、無効な値（ドキュメントによると最小値は5242880）を与え、それを前の値に置きます。テストサーバーのこの値は、目的の321Mに設定されています。

私が言ったように、私はそれを完全にテストしていません。私がしたことは、テストの価値を減らし、アプリケーションを試すことです。すべてが遅くなり、私が投稿した特定のクエリは3分で実行されます。

私は3Gbのより健全な値をテストしましたが、それが良いアイデアであるかどうかはわかりません。そのため、この値について誰かがコメントがあれば、感謝します。

私の結論は、3Gbの「健全な価値」と私がこれに使用した情報は、これら2つの投稿、特に2番目の投稿からのものです。

MySQLクエリ、2つの同様のサーバー、実行時間の2分の違い

mysqlのinnodb_buffer_pool_sizeはどのくらいの大きさにすべきですか？

本番サーバーの値を更新するときに、「実際の」結果を投稿します。

みんなありがとう。

解決した

それで、最終的に製品でこれをテストしました、そしてそれは私が以前にコメントした問題でした。以前のリンクによると、このサイズと使用法のDBの場合は約3Gであるはずですが、innodb_buffer_pool_sizeの値を321Mに設定します。これは、使用するSDKのベンダーが推奨する値です。

ただし、まだ疑問があります。321の値は無効な値（小さすぎる）だったので、MySQLは別の値を取っていました。私の疑いは、それが以前の有効な数、テストで321M、製品で182Mを要したため、速度の違いでした。好奇心が抜けただけなのですが、これが正しいかどうか知りたいです。

助けてくれてありがとう。

私はこれで盲目的に飛んでいるかもしれませんが、ここでそれは行きます...

質問とコメントで、次のように述べています。

両方のサーバーのMySQLバージョンは同じで、設定ファイルも同じです（唯一の違いは、データのパスと、運用サーバーがエラー以外のログを記録しないという事実です）

はい、DBは同じです（実際には、運用DBをテストDBにダンプします）。

同様の結果：安定した方法で2.31Gb

クエリにはEXPLAINプランを提供する必要があります。データは同一であるため、必要ない場合があります。

異なることがいくつかあります

あなたのプロセッサー

私が見上げ2.66GHzの（TEST）@インテルCore 2クワッドQ9400をし、2.40GHz（PROD）@のIntel Xeon E5530との違いを発見しました。

• TESTのCPUには4つのスレッドがあります
• CPU for PRODには8つのスレッドがあります

PRODの方が速いはずです。

その内部バス速度がボトルネックになっている可能性があります。TESTのバス速度が高く、バス乗数が8であるため、これは疑わしいでしょう。バス乗数とは何ですか？

マイクロプロセッサーの内部周波数は通常、フロントサイドバス周波数に基づいています。内部周波数を計算するために、CPUはバス周波数を特定の数で乗算します。これはクロック乗数と呼ばれます。計算には、CPUが有効なバス周波数ではなく実際のバス周波数を使用することに注意することが重要です。デュアルデータレートバス（AMD AthlonおよびDuron）およびクアッドデータレートバス（Pentium 4以降のすべてのIntelマイクロプロセッサ）を使用するプロセッサの実際の実際のバス周波数を決定するには、実効バス速度をAMDの2または4インテル。

これに基づくと、AMD（TEST）の内部バス速度はIntel（PROD）の少なくとも2倍です。

あなたのインデックス統計

TESTに同じデータをロードしたため、見落とされている可能性があります。インデックス統計について考えています。TESTの場合、インデックス統計はかなり新しいものになります。PRODの場合、インデックス付きのテーブルで大量のINSERT、UPDATE、DELETEが発生した場合、古くなる可能性があります。

同一のmysqlバージョン、同一のmysql構成、同一のデータセット、さらには同一のハードウェアを備えた2つの異なるマシンでSELECTを実行すると、関係するテーブルのインデックス統計の影響を受ける可能性があります。

PRODとTESTのすべてのテーブルでANALYZE TABLEを実行してから、パフォーマンスを比較してみます。