シーン
エラーメッセージを図に示します。ロック待機タイムアウトを超えました。初めて発生したとき、同僚はinnodb_lock_wait_timeoutパラメーターを100秒（デフォルトは50秒）に増やしてこの問題を解決しようとしましたが、状況は改善されました。しかし、良い時期は長くは続かず、例外は後で再びスローされ、前の解決策が完全ではなかったことを示しています。mysql関連のコースを深く研究した後（MYSQLの戦闘に関する45の講義を強くお勧めします）、この問題の解決策があります。
分析
| innodb_deadlock_detect（デッドロック検出） | innodb_lock_wait_timeout（デフォルトは50秒） |
|---|---|
| オン（デフォルトで有効） | 有効にする |
| の | 無効 |
ロック待機タイムアウトの例外には2つの可能性があります
- 通常のロック待機
- デッドロックによって引き起こされ
たロック待機を判別するための基本は、データベースパラメータinnodb_deadlock_detectが開いているかどうかを確認することです。開いている場合、デッドロックが発生したときにスローされる例外は、次のような例外である必要があります。デッドロック検出がオンになっている場合、デッドロック待機によって例外が発生することはありません。デッドロック検出がオフになっている場合は、通常のロック待機です。ロックを取得し、実行されていない長いトランザクションが存在する必要があります。長い間リリースされました。これらの2つの異常なシナリオの解決策は次のとおりです。
通常のロック待機
このシナリオによって発生するロック取得タイムアウトは、長いトランザクションに対応している必要があります。解決策は、ロックからロック解除までのプロセス全体を短縮することです。
- SQL実行の習熟度を調整し、追加、削除、および変更されたSQLを最後に配置します
- SQLに複数の追加、削除、および変更がある場合は、最も同時の操作を最後に配置します
- コードを最適化して、コミット開始からコミットまでの時間を短縮します
デッドロック
- ロックからロック解除までのプロセス全体を短縮します（通常のロック待機の解決策）
- デッドロック検出をオンにして、プログラムが例外をキャッチした後に再試行します（CASロック、高速障害+再試行と同様）。不利な点は、デッドロック検出がCPUを消費することです。InnoDBに多数のトランザクションスレッドがある場合、CPU100が発生します。 1秒あたりに処理される％
- デッドロック検出をオフにし、innodb_lock_wait_timeoutを設定し、例外をキャッチしてから再試行します。欠点は、一定時間待機した後に例外がスローされ、応答が遅すぎて、ビジネスが損失を被るということです。
- トランザクションの同時実行量を制御します（クライアントまたはミドルウェアの制御を介して）
- 競合を減らすためのサブデータベースとサブテーブル