mysql触发器会显著拖慢dml操作，因其同步执行、逐行调用且无法异步；应优先用应用层事务、生成列或binlog解析替代，必要时须遵守确定性、禁递归、限写入等硬约束。
触发器会显著拖慢 INSERT/UPDATE/DELETE 操作
MySQL 触发器在对应 DML 语句执行的同一事务中同步运行，无法异步化。只要触发器逻辑复杂、涉及多表查询或写入，就会直接延长主 SQL 的响应时间。尤其在批量操作（如 INSERT INTO ... SELECT 或 LOAD DATA INFILE）时，触发器会被逐行调用，性能衰减呈线性甚至指数级增长。
- 避免在触发器里执行
SELECT查询其他大表——这会引发额外锁等待和 I/O 开销 - 禁止在
BEFORE触发器中修改NEW字段后又依赖该字段做复杂计算，容易引发逻辑混乱和隐式类型转换开销 - 不要在触发器里调用存储过程或自定义函数，除非已确认其内部无锁表、无网络请求、无循环
替代方案比优化触发器更有效
多数业务场景下，“必须用触发器”只是历史惯性。真正需要自动同步或校验的逻辑，往往有更好的实现路径：
- 应用层统一封装：把
INSERT/UPDATE和后续动作（如更新统计表、发消息）放在同一个应用事务里，可控性强、可监控、易回滚 - 使用 MySQL 8.0+ 的
GENERATED COLUMN替代简单计算字段（如full_name VARCHAR(100) AS (CONCAT(first_name, ' ', last_name)) STORED） - 对审计类日志，改用
BINLOG解析（如 Canal、Maxwell）或MySQL Router + 应用监听，完全解耦写入路径
真要用触发器时的关键约束
如果绕不开（例如遗留系统强依赖、DBA 强制要求审计字段），务必遵守以下硬性限制：
iWebShop开源商城系统
下载
iWebShop是一款基于PHP语言及MYSQL数据库开发的B2B2C多用户开源免费的商城系统，系统支持自营和多商家入驻、集成微信商城、手机商城、移动端APP商城、三级分销、视频电商直播、微信小程序等于一体，它可以承载大数据量且性能优良，还可以跨平台，界面美观功能丰富是电商建站首选源码。iWebShop开源商城系统 v5.14 更新日志：新增商品编辑页面规格图片上传优化商品详情页面规格图片与主图切
- 只允许
BEFORE INSERT/BEFORE UPDATE触发器修改NEW值；AFTER类型仅用于日志或通知，禁止反向写入原表 - 触发器体必须是确定性语句：禁用
NOW()、UUID()、RAND()等非确定函数（否则可能造成主从不一致） - 单个触发器内最多执行 1 条
INSERT/UPDATE/DELETE，且目标表不能是当前正在被修改的表（避免递归触发）
DELIMITER $$
CREATE TRIGGER user_updated_at_trigger
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
IF NOT (OLD.name <=> NEW.name OR OLD.email <=> NEW.email) THEN
SET NEW.updated_at = NOW();
END IF;
END$$
DELIMITER ;
监控与定位触发器性能问题
MySQL 不提供触发器单独耗时统计，需通过组合手段发现瓶颈：
- 开启
slow_query_log并设置long_query_time = 0，抓取所有慢操作，再结合EXPLAIN FORMAT=TREE看是否含触发器相关子节点 - 检查
information_schema.TRIGGERS表确认触发器是否存在、状态是否为ENABLED，避免误留废弃触发器 - 用
SHOW PROFILE FOR QUERY N（配合SET profiling = 1）观察某次 DML 的Trigger阶段耗时占比
最常被忽略的是：触发器错误不会中断主 SQL 执行（除非显式 SIGNAL），但会静默失败并留下脏数据。务必在触发器末尾加 IF @@error_count > 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Trigger failed'; END IF; 做兜底。
