すべてのプロダクト
Search
ドキュメントセンター

PolarDB:デッドロック分析

最終更新日:Jun 14, 2025

PolarDB for MySQL が提供するクイック診断機能は、Database Autonomy Service(DAS)の一部の機能と統合されており、デッドロック分析機能を使用してデータベースの最新のデッドロックを分析し、分析の詳細を確認できます。

概要

デッドロック分析機能を使用すると、クラスタのデッドロック、トランザクションブロッキング、およびメタデータロックに対して多次元分析を実行できます。

重要

完全なデッドロック分析その他のデッドロック分析機能を有効にする場合は、次の要件が満たされていることを確認してください。

  1. クラスタが PolarDB for MySQL クラスタであること。

  2. DAS Cost-efficient Edition または DAS Enterprise Edition が有効になっていること。DAS Cost-efficient Edition と DAS Enterprise Edition は一部のリージョンでのみ利用可能です。詳細については、「サポートされているデータベースとリージョン」をご参照ください。DAS Cost-efficient Edition または DAS Enterprise Edition を有効にする方法については、「DAS Economy Edition および DAS Enterprise Edition を有効化および管理する」をご参照ください。

  • 最近のデッドロック分析:DAS は、SHOW ENGINE INNODB STATUS 文の戻り結果にある最新のデッドロックログを分析します。複数のデッドロックが発生した場合、DAS は最新のデッドロックのみを分析します。

  • 完全なデッドロック分析:DAS は、エラーログを定期的に分析し、デッドロック情報を解析し、包括的なデッドロック分析を実行します。DAS では、指定した期間内のデッドロックの傾向を表示したり、各デッドロックの詳細を表示したりすることもできます。

  • その他のロック分析:DAS は、information_schema および performance_schema のデータに基づいて、クラスタの現在のセッションにおけるメタデータロックとトランザクションブロッキングをリアルタイムで分析します。

    • メタデータロック分析:DAS は、information_schema.processlist テーブルなどのテーブルのデータに基づいて、ロック待機関係を推測し、対応する図を生成します。

    • トランザクションブロッキング分析:DAS は、information_schema.processlistinformation_schema.innodb_trx、および information_schema.innodb_lock_waits または performance_schema.data_lock_waits テーブルのデータに基づいて、トランザクションブロッキング関係を分析し、対応する図を生成します。 information_schema.innodb_lock_waits テーブルのデータは MySQL 5.6 または MySQL 5.7 を実行するクラスタに使用され、performance_schema.data_lock_waits テーブルのデータは MySQL 8.0 を実行するクラスタに使用されます。

      説明

      トランザクションブロッキング分析機能は、MySQL 5.6 を実行する PolarDB for MySQL クラスタではサポートされていません。

パラメータ設定

クラスタでデッドロック分析機能を使用するには、クラスタの対応するパラメータを設定する必要があります。次の表に、さまざまなデッドロック分析機能に必要なパラメータ設定を示します。

デッドロック分析機能

必要なパラメータ設定

最近のデッドロック分析

innodb_deadlock_detect パラメータを ON に設定します。

完全なデッドロック分析

  • innodb_deadlock_detect パラメータを ON に設定します。

  • innodb_print_all_deadlocks パラメータを ON に設定し、log_error_verbosity を 3 に設定します。

その他のロック分析トランザクションブロッキング分析

PolarDB for MySQL クラスタが MySQL 8.0 を実行している場合は、performance_schema パラメータを ON に設定します。

PolarDB for MySQL クラスタのパラメータを変更する方法については、「クラスタとノードのパラメータを設定する」をご参照ください。

手順

  1. PolarDB コンソール にログインします。左側のナビゲーションウィンドウで、クラスター をクリックします。左上隅で、クラスタのリージョンを選択します。クラスタリストで、クラスタ ID をクリックして [基本情報] ページに移動します。

  2. 左側のナビゲーションウィンドウで、診断と最適化 > クィック診断 を選択します。

  3. [デッドロック分析] タブをクリックします。

  4. [デッドロック分析] ページで、[現在のノード] ドロップダウンリストからターゲットクラスタ ID を選択し、[診断] をクリックします。

  5. 検出された最新のデッドロックについて、[詳細] 列の [詳細の表示] をクリックします。

    説明

    [詳細の表示] ボタンは、同じ項目の [デッドロック検出] 列が [はい] 状態に表示されている場合にのみ使用できます。

  6. [デッドロック分析] ダイアログボックスで、デッドロック分析結果の詳細を表示します。 [デッドロックログの表示] をクリックして、最新のデッドロックログの詳細を表示できます。

よくある質問

UPDATE 文を実行すると、なぜデッドロックが発生するのですか?どのように解決できますか?

デッドロックは、2 つのトランザクションが対応するレコードに対して排他ロック(X ロック)を保持し、同時に相手が保持しているロックを取得しようとすると発生します。次に例を示します。

  • トランザクション 1 は UPDATE accounts SET balance = balance - 100 WHERE user_id = 1; 文を実行し、ユーザー A のアカウント(id=1)に対する排他ロックを取得します。

  • トランザクション 2 は UPDATE accounts SET balance = balance + 100 WHERE user_id = 2; を実行し、ユーザー B のアカウント(id=2)に対する排他ロックを取得します。

説明

このシナリオでは、各トランザクションは異なるレコードに対して排他ロックを保持しています。トランザクション 1 が user_id=2 のレコードに対して排他ロックを取得しようとし、トランザクション 2 が user_id=1 のレコードに対して排他ロックを取得しようとすると、ロックが他のトランザクションによって保持されているため、デッドロックが発生します。

解決策:すべてのトランザクションが同じ順序でレコードを更新するようにします。たとえば、常に ID が小さいレコードから更新します。または、複数の更新操作を 1 回のバッチ更新にまとめることで、ロックの競合を減らすことができます。