触发器验证必须通过可控输入、可观察输出和事务隔离进行，禁用SELECT *模拟，需用BEGIN TRANSACTION+ROLLBACK测试真实DML路径，并覆盖批量、并发、NEW/OLD处理及跨表原子性缺陷。
触发器是否符合业务规则，不能靠“看起来没报错”来判断——它可能静默改错数据、在批量场景下漏判、或只对单行有效。必须用可控输入+可观察输出+事务隔离的方式验证。
用构造数据 + ROLLBACK 测试真实执行路径
触发器运行在真实 DML 语句上下文中，脱离 INSERT/UPDATE/DELETE 就测不准。比如 BEFORE UPDATE 里修改 NEW.field 的行为，只有真正执行 UPDATE 才会生效。
- 始终用
BEGIN TRANSACTION包裹测试语句，结尾跟ROLLBACK，避免污染数据 - MySQL 和 PostgreSQL 都支持在事务中触发触发器；SQL Server 必须显式开启事务（
SET IMPLICIT_TRANSACTIONS ON或写BEGIN TRAN） - 别用
SELECT * FROM table LIMIT 1模拟触发——它根本不会调用触发器 - 测试时关闭自动提交（
SET autocommit = 0），否则ROLLBACK无效
检查 NEW/OLD 值是否被正确读取和修改
触发器逻辑依赖 NEW 和 OLD 的值，但不同数据库对它们的可见性、可写性、字段引用语法差异极大。
- PostgreSQL 中不能直接写
SELECT id FROM NEW，会报missing FROM-clause entry for table "new"；必须先声明变量，再用SELECT ... INTO赋值 - MySQL 允许
IF NEW.amount < 0 THEN SIGNAL ...，但禁止在条件里嵌套标量子查询（如IF (SELECT COUNT(*) FROM ...) > 0），会报ERROR 1356 -
BEFORE触发器中可写NEW.field := value（PostgreSQL）或SET NEW.field = value（MySQL），但修改后是否被后续逻辑使用，必须实测确认 - SQL Server 没有
NEW/OLD，要用INSERTED和DELETED临时表，且注意它们在AFTER中才可用，INSTEAD OF中需手动处理
覆盖批量操作与并发边界场景
单条语句正常，不等于业务规则真成立。90% 的触发器缺陷暴露在批量或并发下。
- 用
INSERT INTO t VALUES (...), (...), (...)测试多行插入——MySQL/PostgreSQL 的FOR EACH ROW是逐行触发，但子查询若没加WHERE条件，可能误扫全表 - 模拟并发：开两个会话，同时执行相同 INSERT，检查是否出现幻读导致重复通过校验（如订单号查重没加
SELECT ... FOR SHARE或FOR NO KEY UPDATE） - 测试
UPDATE t SET status = 'done' WHERE id IN (1,2,3)——确认触发器是否对每行独立计算OLD.status和NEW.status，而非取整批的聚合值 - 特别验证时间类逻辑：比如 “24 小时内不可重复提交”，用
NOW()在触发器里查，要确保测试时能控制时间戳，否则结果不可复现
把触发器逻辑抽成独立函数再测
直接测触发器就像黑盒调试；抽成函数后，你可以传任意 NEW/OLD 模拟值，还能加日志、断点、单元测试。
- PostgreSQL：用
CREATE OR REPLACE FUNCTION test_handler() RETURNS TRIGGER，然后SELECT test_handler() OVER ()或手动构造ROW()传参 - MySQL：没有原生 RECORD 类型，建一张结构相同的临时表，插入测试数据，再在该表上跑等价 SQL（如
SELECT ... FROM temp_table WHERE order_no = ?） - SQL Server：把触发器主体逻辑拆进存储过程，用
INSERTED表参数模拟输入，避免硬编码表名 - 所有函数测试前，固定时间字段（如传入
@as_of_time DATETIME替代GETDATE()），否则每次结果可能不同
最常被忽略的点是：触发器不保证原子性跨表操作。比如它查了 A 表状态、再更新 B 表，中间若被其他事务修改 A 表，就产生逻辑错位——这种问题只能靠应用层加锁或改用分布式事务，触发器本身无解。
