触发器没执行？先确认DML是否真触发事件：MySQL 8.0+对无效UPDATE（如SET a=a）默认跳过触发器，需检查sql_mode含STRICT_TRANS_TABLES，并确保操作真实修改数据。
触发器没执行？先确认 DML 是否真触发了事件
MySQL 触发器只在明确的 INSERT/UPDATE/DELETE 语句执行且实际修改数据时才运行。如果 UPDATE t SET status = status 这种“无效更新”，MySQL 8.0+ 默认跳过触发器（受 STRICT_TRANS_TABLES 影响），连错误都不会报。所以自动化脚本第一步不是查日志，而是确保测试语句真正“动”了数据：
- 用
SELECT @@sql_mode;检查是否含STRICT_TRANS_TABLES，必要时临时关闭（仅测试环境） - 测试 UPDATE 时，必须让字段值发生真实变化，比如
UPDATE orders SET updated_at = NOW() WHERE id = 123 - INSERT 测试要避开唯一键冲突，DELETE 要确认行存在——否则整个语句失败，触发器根本不会进入
写自动化验证脚本：用最小 SQL + 显式断言
别依赖日志或人工看表，直接在脚本里做可预期的“前后快照 + 断言”。核心是：对一张被触发器影响的表，执行操作前查一次状态，操作后再查，比对是否符合逻辑。例如一个 before_insert_update_timestamp 触发器自动设 created_at 和 updated_at：
SET @before_created = (SELECT created_at FROM users WHERE id = 999); INSERT INTO users (id, name) VALUES (999, 'test'); SET @after_created = (SELECT created_at FROM users WHERE id = 999); SELECT IF(@after_created IS NOT NULL AND @before_created IS NULL, 'PASS', 'FAIL') AS result;
要点：
- 所有查询用
SELECT ... INTO @var或子查询赋值，避免客户端解析结果集带来的不确定性 - 触发器若影响多张表（如日志表），脚本里必须显式查那张目标表，比如
SELECT COUNT(*) FROM audit_log WHERE table_name = 'users' - 用
IF(..., 'PASS', 'FAIL')直接输出判定结果，方便 CI 工具抓取
跨库、权限、DEFINER 导致静默失败怎么办
触发器里写了 INSERT INTO log_db.audit_log 却没反应？不是语法错，是权限或上下文问题。自动化脚本不能只跑业务逻辑，还得提前兜底检查：
- 执行前先查
SELECT COUNT(*) FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'log_db'，确认库存在 - 用当前连接用户查
SELECT COUNT(*) FROM log_db.audit_log，验证是否有 SELECT 权限（很多触发器只写不读，但脚本要读来断言） - 若触发器定义含
DEFINER='admin'@'%'，而目标库没该用户，导入时会跳过或报错ERROR 1449；脚本开头加一句SELECT USER();确认当前上下文，再决定是否用SET SESSION sql_mode = ''降级兼容
为什么不能只靠 SHOW TRIGGERS 就认为它“生效”
SHOW TRIGGERS 只说明定义存在，不保证能跑通。触发器里调用了已删除的函数、引用了重命名的字段、或用了 MySQL 8.0 废弃的 ENCRYPT()，CREATE TRIGGER 仍会成功，但第一次 DML 就崩在 ERROR 1362。自动化脚本必须包含“真实执行路径”：
- 在测试表上执行一次完整 DML，立刻跟
SHOW WARNINGS;—— 这是唯一能捕获触发器内部错误的方式 - 把
SHOW WARNINGS;结果查进变量，匹配'Error'或'Warning'关键字，有就标 FAIL - 特别注意
ERROR 1415 (0A000)：触发器里写了裸SELECT，MySQL 5.7+ 直接拒绝，但SHOW TRIGGERS看不出
复杂点在于触发器之间可能有顺序依赖，而 mysqldump 不保证导出顺序。如果脚本验证通过但上线后出问题，大概率是多个触发器对同一行反复改导致覆盖——这种只能靠业务侧构造多步操作链路来测，没法靠单条 SQL 自动化覆盖。
