触发器在批量INSERT时逐行执行，导致性能骤降、锁竞争加剧；应避免跨行/跨表操作，仅保留单行无副作用逻辑，复杂场景改用应用层或存储过程显式控制事务。
触发器在批量 INSERT 时会为每一行单独执行，不是“一次触发、批量处理”，这是性能崩塌的根源。哪怕只加一个简单 BEFORE INSERT，插入 10 万行也可能慢 3～5 倍。
触发器里每行都执行一次，根本停不下来
MySQL 不支持“批量触发”语义：即使你用 INSERT INTO t VALUES (a,1),(b,2),(c,3) 插入三行，BEFORE INSERT 也会被调用三次，每次看到的是 NEW.a、NEW.b、NEW.c 中的一个值。这意味着：
- 触发器内所有逻辑（包括
SELECT、UPDATE、函数调用）都会重复执行 N 次 - 如果触发器里有
SELECT COUNT(*) FROM log WHERE status = NEW.status，就会做 N 次全表扫描（除非status有索引且命中） - 锁竞争加剧：多行同时触发，可能争抢同一行或同一页的锁，导致大量
Lock wait timeout exceeded
避免在触发器中做任何跨行/跨表操作
只要触发器逻辑依赖“其他行”或“其他表”，就天然和批量插入冲突。典型高危写法：
-
UPDATE stats SET total = total + 1 WHERE type = NEW.category—— 多行并发更新同一行，死锁高发 -
SELECT MAX(seq) FROM history WHERE user_id = NEW.user_id—— 每行都查一遍，没索引就全表扫 -
INSERT INTO audit_log (...) VALUES (...)—— 把审计日志也塞进主事务，放大事务体积
正确做法是剥离：统计类改用应用层定时聚合；审计日志走消息队列异步落库；关联校验类逻辑移到应用层或用 ON DUPLICATE KEY UPDATE 合并处理。
用存储过程替代触发器时必须显式事务控制
把原来分散在多个触发器里的逻辑收进一个 proc_bulk_insert，不代表自动变快——反而更容易出错：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 没加
DECLARE EXIT HANDLER FOR SQLEXCEPTION→ 出错后部分数据已写入，事务不回滚 - 误以为“一次调用=一次事务”，实际仍需手动
START TRANSACTION/COMMIT - 原
BEFORE校验 +AFTER日志的顺序，在存储过程中必须显式拆解，否则一致性丢失
示例关键结构：
DELIMITER //
CREATE PROCEDURE proc_bulk_insert(IN data_list JSON)
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK;
RESIGNAL;
END;
<p>START TRANSACTION;
-- 步骤1：校验（对应 BEFORE）
IF NOT EXISTS (SELECT 1 FROM whitelist WHERE code = JSON_EXTRACT(data_list, '$[0].code')) THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid code';
END IF;</p><p>-- 步骤2：主表插入（批量）
INSERT INTO orders (...) SELECT ... FROM JSON_TABLE(...);</p><p>-- 步骤3：补日志（对应 AFTER，但异步更佳）
INSERT INTO audit_log (...) VALUES (...);
COMMIT;
END //</p>
真正要保留的触发器逻辑，必须满足“单行无副作用”
如果业务强要求某些字段必须由数据库生成（如自增编码、时间戳归一化、敏感字段脱敏），那触发器可以留，但必须遵守：
- 只读取
NEW.*字段，不查表、不调函数、不写表 - 所有计算在内存完成，比如
SET NEW.created_at = NOW(3)、SET NEW.code = CONCAT('ORD-', UNIX_TIMESTAMP()) - 避免
UUID()这类非确定性函数，会导致主从不一致或 binlog 复制失败 - 确认该字段没有被应用层覆盖 —— 否则触发器赋值会被静默丢弃
复杂度藏在细节里：你以为只是加个时间戳，但如果 NOW() 被用于生成唯一键前缀，而并发插入又没加锁，就可能撞码。这种坑不会报错，只会悄悄污染数据。
