はじめに
データベース管理者（DBA）として日々システムの運用を行っていると、特定のテーブルに対する操作をフックにして、別のテーブルへの書き込みやログの記録、あるいはデータ整合性の強制を行いたいという要件に頻繁に出会います。その際、最も強力かつ慎重に扱うべきツールが「トリガー」です。
トリガーを使いこなす上で避けて通れないのが、今回テーマとして取り上げる「OLD」と「NEW」という擬似レコードです。これらを理解することは、単にSQLが書けるというレベルから、データのライフサイクルを設計できるエンジニアへの第一歩です。今回は、実務の現場で直面しがちな課題を交えつつ、OLDとNEWの挙動と注意点について深掘りしていきます。
OLDとNEWの基本的な役割
トリガー内で利用可能なOLDとNEWは、トリガーが起動した対象テーブルの「変更前」と「変更後」のデータを保持する特別な変数です。
まず、それぞれの役割を整理しましょう。
・NEW: INSERTまたはUPDATE文によって「これから書き込まれる（あるいは更新される）」新しい値です。
・OLD: UPDATEまたはDELETE文によって「削除される（あるいは更新される前の）」古い値です。
例えば、あるテーブルの特定のカラムが更新されたことを検知して履歴テーブルに書き込む場合、OLDには「更新前」の値を、NEWには「更新後」の値を保持させることで、差分管理が可能になります。
コード例：更新履歴を自動記録するトリガー
実務では、ユーザーの操作履歴やデータの変更履歴を別テーブルに保存したいという要望がよくあります。以下は、MySQLを例とした基本的なトリガーの実装例です。
—
CREATE TABLE users (
id INT PRIMARY KEY,
username VARCHAR(50),
email VARCHAR(100)
);
CREATE TABLE user_audit_log (
id INT AUTO_INCREMENT PRIMARY KEY,
user_id INT,
old_email VARCHAR(100),
new_email VARCHAR(100),
changed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
DELIMITER //
CREATE TRIGGER after_users_update
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.email <> NEW.email THEN
INSERT INTO user_audit_log (user_id, old_email, new_email)
VALUES (OLD.id, OLD.email, NEW.email);
END IF;
END;
//
DELIMITER ;
—
この例では、UPDATE文が実行された際に、メールアドレスが変更されているかを確認し、変更がある場合のみ履歴テーブルにレコードを追加しています。ここで重要なのは、OLD.emailとNEW.emailを比較することで、実際に値が変わったときだけアクションを起こすという「無駄な処理を省く」設計です。
実務における注意点：NULLの扱いに潜む罠
OLDとNEWを扱う際、DBAとして最も注意すべきは「NULL」の扱いです。
先ほどのコード例で、もしemailカラムがNULLを許容している場合、OLD.email <> NEW.email という比較は意図通りに動作しません。SQLの標準では、NULLとの比較結果はUNKNOWNとなり、IF文の条件式が偽として扱われてしまうからです。
実務においては、以下のようにNULLセーフな比較演算子（MySQLであれば <=>）を使用するか、IS NULLチェックを明示的に行う必要があります。
—
IF NOT (OLD.email <=> NEW.email) THEN
— ここに処理
END IF;
—
このように、わずかな記述の違いがデータ不整合やログ漏れを招くことがあります。特に、アプリケーション側から送られてくるデータの型が曖昧な場合、トリガー側で厳密にチェックを行うことがシステム全体の堅牢性を担保します。
トリガー内でNEWの値を変更するメリット
BEFORE UPDATEやBEFORE INSERTトリガーを使用する場合、NEWの値を書き換えることが可能です。これは「入力データのクレンジング」や「自動採番の補完」に非常に有効です。
例えば、ユーザーが入力した文字列から不要な空白を取り除いたり、特定のフラグを強制的に上書きしたりする場合です。
—
CREATE TRIGGER before_users_insert
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
SET NEW.email = LOWER(TRIM(NEW.email));
END;
//
—
このように、アプリケーション層での実装漏れを防ぐ「最後の砦」としてトリガーを活用できます。ただし、ビジネスロジックをデータベース側に詰め込みすぎると、アプリケーションの変更時にDB側も修正が必要になり、依存関係が複雑化します。ロジックの所在については常に議論が必要です。
パフォーマンスへの影響と設計指針
トリガーは便利ですが、多用するとパフォーマンスに悪影響を与えます。特に、大量のデータを一括更新するバッチ処理において、トリガーが1行ごとに起動される場合、処理時間は線形的に増加します。
実務で私が推奨しているのは、以下の3点です。
1. トリガーのロジックは極力シンプルに保つ:
トリガー内での複雑なJOINや、外部APIの呼び出し（一部のDBエンジンでは可能ですが厳禁です）は避けるべきです。
2. 実行条件を絞り込む:
特定のカラムが変更されたときのみ処理が走るように条件分岐を徹底します。
3. ログ記録は非同期を検討する:
監査ログなどの書き込みは、トリガーで行うとメイン処理のレスポンスを悪化させます。可能であれば、アプリケーション側でキューイングして非同期で処理する設計が理想的です。
デバッグの難しさとテストの重要性
トリガーの最大の弱点は「目に見えない」ことです。アプリケーションのコードには現れないため、後任のエンジニアが原因不明のデータ更新に頭を抱えることがよくあります。
これを防ぐためには、以下の対応が必要です。
・命名規則の徹底:
トリガー名には対象テーブル名とタイミング（AFTER/BEFORE）、操作（INSERT/UPDATE）を明記する。
・ドキュメント化:
DDLだけでなく、トリガーが存在する目的をWikiや設計書に明記する。
・単体テスト:
トリガー専用のテストケースを作成し、特定のカラム更新時に期待通りの履歴が残るか、あるいは期待通りに値が変換されるかを検証する自動テストをCIに組み込む。
まとめ：道具としてのトリガーを使いこなす
OLDとNEWは、データベースという巨大な情報の海において、その変化を捉えるための「レンズ」のような存在です。正しく使えば、データ整合性の維持や自動監査といった強力な武器になります。一方で、無計画な使用はパフォーマンス低下やデバッグ困難なバグの温床にもなり得ます。
実務においては、以下の問いを常に自分自身に投げかけてください。
「このロジックは、本当にデータベーストリガーで行うべきか？ アプリケーション層で処理できないか？」
もし、データそのものの整合性を守るための最後の砦としてトリガーを選択するのであれば、今回紹介したOLDとNEWの特性を理解し、NULLやパフォーマンスへの配慮を怠らないようにしてください。
データベースを単なるデータの保管庫としてではなく、インテリジェントなシステムの一部として機能させるためには、こうした地味ながらも重要な機能をいかに使いこなすかが、DBAとしての腕の見せ所です。この記事が、皆さんの日々の運用業務やデータベース設計の一助となれば幸いです。
最後に、トリガーを導入する際は必ずステージング環境で負荷試験を行い、本番環境への影響を最小限に抑えるよう心がけてください。それでは、素晴らしいデータベースライフを。
コメント