MySQL 触发器没有内置调试器，只能靠日志和模拟验证
MySQL 本身不提供类似存储过程的
DEBUG模式，也不支持断点、单步执行或变量监视。触发器在
INSERT/
UPDATE/
DELETE语句执行时隐式调用，无法独立运行，因此「调试」本质是「间接观测 + 主动注入诊断逻辑」。
常用做法是在触发器体中插入日志记录，例如写入临时表或系统表（需注意权限）：
CREATE TABLE debug_log (
id INT AUTO_INCREMENT PRIMARY KEY,
msg TEXT,
ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
DELIMITER $$
CREATE TRIGGER test_before_insert
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
INSERT INTO debug_log(msg) VALUES (CONCAT('NEW.id=', NEW.id, ', NEW.name=', COALESCE(NEW.name, 'NULL')));
END$$
DELIMITER ;
注意：
SELECT或
SIGNAL可用于中断流程并暴露变量值，但会改变业务行为；
INSERT INTO日志表是最轻量、最可控的调试方式。 避免在生产环境长期启用日志写入，尤其高频表，否则显著拖慢性能 不要在触发器里调用存储函数或访问远程表——可能引发锁等待或超时
NEW和
OLD在
AFTER触发器中仍可读，但修改它们无效（仅
BEFORE允许赋值）
用 SHOW PROFILES
和 EXPLAIN
分析触发器开销不直接有效
SHOW PROFILES只显示 SQL 语句级耗时，不会拆分出触发器执行时间；
EXPLAIN对 DML 语句也完全不展示触发器路径。触发器性能必须通过「对比测试」来定位： 先禁用触发器：
ALTER TABLE tbl DISABLE TRIGGER trigger_name（MySQL 8.0.19+ 支持） 对同一条
INSERT/UPDATE语句分别运行两次：一次启用，一次禁用 用
BENCHMARK()或客户端计时工具（如
mysqlslap）测平均延迟差异 检查
INFORMATION_SCHEMA.TRIGGERS确认触发器定义是否含低效操作（如子查询、循环、大字段处理）
特别注意：
BEFORE触发器中对
NEW字段的计算如果涉及函数（如
UUID()、
NOW()、正则匹配），会在每行都重复执行；而
AFTER中的
INSERT INTO ... SELECT可能引发隐式全表扫描。
触发器性能瓶颈常见于隐式锁与事务膨胀
触发器代码运行在主 DML 事务上下文中，所有操作共享同一事务 ID 和锁范围。一个看似简单的触发器可能意外扩大锁粒度或延长事务持有时间：
在BEFORE UPDATE中执行
SELECT ... FOR UPDATE会提前加锁，可能造成死锁 触发器内更新另一张大表（如日志归档表），会使主事务变长，阻塞其他并发操作 多个触发器链式调用（A → B → C）时，MySQL 不做优化合并，每一层都走完整解析+执行流程 使用
ROW_FORMAT=COMPRESSED表 + 触发器中的大文本操作，可能触发频繁页分裂
可通过
SHOW ENGINE INNODB STATUS\G查看最近死锁详情，重点观察
TRANSACTIONS部分中触发器相关 SQL 的锁等待链。
替代方案比硬调触发器更值得优先考虑
多数业务场景下，把逻辑移到应用层或使用
GENERATED COLUMN/
CHECK约束更可控、更易测试： 自动生成字段（如
created_at、
full_name）用
AS表达式列，零运行时开销 数据一致性校验优先用
CHECK约束（MySQL 8.0.16+），失败报错明确且不依赖执行顺序 跨表同步类逻辑（如订单创建后扣减库存）改用应用层事务 + 幂等设计，便于监控和补偿 审计日志类需求用
general_log或代理层（如 ProxySQL）捕获原始语句，比触发器更稳定
真正需要触发器的场景其实很窄：必须保证数据库端强一致、且无法改造应用逻辑的历史系统。这时候，务必限制其只做轻量字段修正或简单状态标记，别让它碰网络、文件、复杂计算。
