MySQL触发器并发写入变慢的根本原因是将异步逻辑强塞进同步事务，如SELECT查大表、无索引WHERE或NOW()调用均可致吞吐降50%以上；应禁用触发器内查询、改用应用预加载或中转表+外部消费。
MySQL 触发器在大表上并发写入变慢，根本原因不是“触发器太重”，而是它强制把本该异步、解耦的逻辑塞进了同步事务里——只要触发器里有一行 SELECT 查大表、一个没索引的 WHERE 条件、甚至一次 NOW() 调用，写入吞吐就可能掉 50% 以上。
触发器里查大表为什么直接卡住 INSERT
触发器中的 SELECT 在当前事务隔离级别下执行，若目标表无合适索引或查询条件无法命中索引最左前缀，就会走全表扫描或间隙锁（Gap Lock），导致：
- 其他并发 INSERT/UPDATE 因锁等待被阻塞
- SHOW PROCESSLIST 中大量线程卡在 Sending data 或 Updating 状态
- 慢查询日志里 INSERT 的耗时远高于语句本身，实际是触发器里的 SELECT 在拖后腿
实操建议：
- 彻底删掉触发器内的 SELECT，把关联数据提前查好、随主 SQL 一起传入（应用层预加载）
- 必须查时，只允许用主键或唯一键查单行，且被查字段必须有覆盖索引（如 WHERE user_id = NEW.user_id → 索引为 (user_id)）
- 禁止在 BEFORE INSERT 里查正在插入的同一张表（MySQL 报错 Can't update table 't' in stored function/trigger）
AFTER INSERT 触发器里写日志表也慢？检查这张表的引擎和索引
很多人以为“只是写一行日志”，但日志表如果用默认 InnoDB + 多个二级索引，在高并发下会迅速成为瓶颈：每写一行都要维护聚簇索引 + N 个二级索引 B+ 树，页分裂频繁，innodb_row_lock_waits 明显上升。
实操建议：
- 日志类中转表优先用 ENGINE=BLACKHOLE（仅丢弃）或 ENGINE=MEMORY（需控制数据量）
- 若必须落盘，用 InnoDB 但只建必要索引（比如只按 created_at 查询，就只建 (created_at) 单列索引）
- 避免在触发器里调 INSERT INTO log_table SELECT ... 这种带子查询的写法——它会放大锁范围和执行计划开销
- 更稳妥的做法：触发器只做 INSERT INTO trigger_queue (id, table_name, event_type) VALUES (NEW.id, 'orders', 'insert')，一行、无条件、无函数
批量 INSERT 时触发器性能断崖式下跌？别让它逐行执行
INSERT INTO t1 SELECT * FROM t2 LIMIT 10000 这类操作会让触发器执行 10000 次，哪怕每次只花 0.3ms，总延迟也超 3 秒，且期间锁持有时间拉长，极易触发 Lock wait timeout exceeded。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
- 批量导入前，用 ALTER TABLE t1 DISABLE TRIGGER trigger_name（MySQL 8.0.19+ 支持）临时禁用
- 禁用后执行完再 ENABLE，避免误删数据或漏审计
- 如果业务强依赖触发器行为（如自动生成流水号），改用应用层批量构造完整数据后再单次 INSERT，把触发逻辑前置
- 线上严禁用 INSERT DELAYED——它早在 MySQL 5.6 就废弃，8.0 完全删除，搜到的教程都是过期文档
真要异步，别在数据库里硬刚，用中转表 + 外部消费者
MySQL 本身不支持异步触发器。所谓“异步”，本质是把耗时操作移出事务边界。靠 AFTER INSERT 写中转表 + 外部进程消费，才是可控、可监控、可重试的方案。
实操建议：
- 中转表结构极简：id BIGINT PK, table_name VARCHAR(64), event_type ENUM('insert','update'), created_at TIMESTAMP，引擎用 InnoDB 并确保 innodb_buffer_pool_size 足够缓存热数据
- 消费者用 Python/Go 写，长轮询或定时拉取（如 SELECT * FROM trigger_queue WHERE status = 'pending' LIMIT 100），处理完立刻 UPDATE ... SET status = 'done' 或 DELETE
- 消费失败必须重试，但中转表要加 status 和 retry_count 字段防死循环
- 别用消息队列（如 Kafka）替代中转表——除非你已具备完整的 MQ 运维能力；对多数业务，“一张轻表 + 一个常驻进程”更简单可靠
最容易被忽略的一点：触发器是否真的不可替代？很多场景下，GENERATED COLUMN（MySQL 8.0+）、应用层事务封装、甚至 binlog 解析（Canal/Debezium）都能比触发器更稳更快。别让“历史有触发器”变成继续用它的理由。
