クエリ ログを再生しないことをお勧めします。ほとんどの場合、必要な情報が得られず、かなりの労力がかかります。
まず、データの挿入、更新、または削除の際にクエリ ログを再生しても制約が破られないように、また後続の「選択」クエリで必要なレコードが検出されるように、データベースを準備する必要があります。これは、おもちゃのデータベース以外では明らかに些細なことではありません。バックアップを取ってログを再生するだけでは、DML ステートメントの順序が本番環境で発生したものと一致するとは限りません。これは間違った安心感を与えてしまうかもしれません。探しているデータが存在しないため、すべての select ステートメントが数ミリ秒で返されます!
第二に、負荷とパフォーマンスのテストは、本番環境で発生したことを再現することによってほとんど機能しません。これは、(通常) システムを停止させるピーク条件を反映していません。たとえば、ほとんどの本番システムは、ほとんどの場合 50% 未満の容量で正常に動作しますが、日中はスパイクが発生し、容量の 80% 以上に達する可能性があります。これは、新しい環境がピークを処理できるかどうかに注意してください。 .
JMeterのようなツールを使用してパフォーマンス スクリプトを作成することをお勧めします (JDBC ドライバーを使用してデータベースに直接、または Web アプリケーションを使用している場合はフロント エンドを介して)。パフォーマンス スクリプトは、ユーザーから見た動作を反映し、パラメータ化して、レコードが作成される順序に依存しないようにする必要があります。
いくつかのパフォーマンス目標を設定し (理想的には、現在の生産レベルに基づいて、スパイクをカバーするための乗数を使用します)、たとえば「100 人の同時ユーザー、1 秒以上かかるクエリはありません」)、JMeter を使用してその負荷をシミュレートします。初めて到達した場合は、おめでとうございます - 家に帰りましょう! そうでない場合は、パフォーマンス カウンターを見て、ボトルネックがどこにあるかを確認します。そのボトルネックを軽減できるかどうかを確認してください (またはクエリを調整すると、優れたオンプレミス ハードウェアがパフォーマンスの問題を隠している可能性があります)。一般的なボトルネックは、CPU、RAM、およびディスク I/O です。
さまざまなテスト シナリオ (「多数の書き込み」、「多数の読み取り」、「多数のレポート クエリ」) を試して、それらを混ぜ合わせます。
アイデアは、システムのボトルネックを理解し、それらのボトルネックからどれだけ離れているかを確認し、それらを軽減するために何ができるかを理解することです. それがわかれば、移行の決定ははるかに確実になります。