MySQLでトリガー実行中のエラーを処理する仕組みを徹底解説

MySQLでは、トリガー（trigger）の実行中にエラーが発生した場合でも、一定のルールに従って適切に処理が行われます。ここでは、BEFOREトリガーとAFTERトリガーそれぞれの挙動や、テーブルの種類によるロールバックの違いについて詳しく解説します。

トリガー実行中にエラーが発生した場合の基本的な動作

1. BEFOREトリガーが失敗した場合

BEFOREトリガーが失敗すると、該当する行に対する操作（INSERT・UPDATEなど）は一切実行されません。これにより、不正なデータがテーブルに書き込まれるのを未然に防ぐことができます。

2. BEFOREトリガーは操作の成否にかかわらず起動される

BEFOREトリガーは、行を挿入または更新しようとする「試み」が行われた時点で起動されます。そのため、その後の操作自体が成功するかどうかにかかわらず、トリガーは必ず実行される点に注意が必要です。

3. AFTERトリガーは成功時にのみ実行される

AFTERトリガーは、すべてのBEFOREトリガーおよび対象行への操作が正常に完了した場合にのみ実行されます。前段階でエラーが発生していれば、AFTERトリガーは実行されません。

4. エラー発生時はステートメント全体が失敗する

BEFOREトリガーまたはAFTERトリガーのいずれかでエラーが発生すると、そのトリガーを呼び出したSQLステートメント全体が失敗したものとして扱われます。

トランザクション対応テーブルと非トランザクションテーブルの違い

トランザクション対応テーブル（InnoDBなど）の場合

ステートメントが失敗すると、そのステートメントによって実行されたすべての変更がロールバックされます。トリガーの失敗はステートメント全体の失敗につながるため、結果としてトリガー内の変更も含めてすべて元に戻されます。

非トランザクションテーブル（MyISAMなど）の場合

非トランザクションテーブルではロールバックが行えないため、たとえステートメント自体が失敗しても、エラー発生時点までに実行された変更はそのまま残ります。この点はデータ整合性の観点から特に注意が必要です。

まとめ

MySQLのトリガーエラー処理は、「BEFOREトリガーの失敗＝行操作の中止」「AFTERトリガーは全処理成功後に実行」「エラー時はステートメント全体が失敗」という基本原則に基づいています。さらに、使用しているストレージエンジンがトランザクションに対応しているかどうかで、ロールバックの可否が変わるため、設計時にはテーブルの特性を十分に考慮することが重要です。