必须将触发器移出事务边界，因其与主sql共享事务上下文，导致锁持有时间延长、延迟激增、链式阻塞及死锁；应改用消息表等异步机制，仅保留毫秒级无io操作在触发器内。
高并发下触发器卡住，本质是把本该异步做的事硬塞进同步事务里。直接改用消息队列或异步处理，不是“绕开问题”，而是回归数据库职责边界——它只管数据原子性，不负责通知、统计、缓存更新这些副作用。
为什么触发器必须移出事务边界
触发器在 AFTER INSERT 或 BEFORE UPDATE 中执行时，和主 SQL 共享同一个事务上下文。只要它里面有一次 SELECT ... FOR UPDATE、一次没索引的点查、甚至只是调用一个含 SELECT 的存储函数，整个事务就得等它完成才能提交。500 QPS 下，平均延迟从 0.8ms 涨到 12ms 就是因为这个等待链。
- 锁持有时间 = 主SQL执行时间 + 触发器内所有SQL执行时间 + 函数解析/权限检查开销
- 一旦触发器写入日志表、调用外部API、或更新另一张带触发器的表，就可能引发链式阻塞或死锁
- MySQL 不支持
pg_trigger_depth()这类嵌套深度检测，递归触发只能靠业务层加标记字段硬防
用轻量消息表替代直接写队列服务
不是所有系统都已接入 Kafka 或 RabbitMQ。更务实的做法，是建一张极简的 trigger_queue 表，用 MySQL 自身机制模拟异步：在触发器里只做一件事——INSERT INTO trigger_queue (table_name, row_id, event_type, created_at) VALUES ('orders', NEW.id, 'insert', NOW())。
- 这张表必须只有几个字段，引擎用
InnoDB，主键为自增id，其他字段加INDEX(event_type, created_at) - 避免在触发器里对
trigger_queue做UPDATE或DELETE，否则又引入新锁 - 消费者任务（如每 100ms 跑一次的定时脚本）用
SELECT ... FOR UPDATE LIMIT 100拉取并标记处理中，再异步执行后续逻辑 - 别在触发器里写
INSERT ... SELECT多行进trigger_queue，批量操作会触发 N 次插入，N 行就写 N 条队列记录
哪些逻辑必须异步，哪些还能留在触发器里
能留在触发器里的，仅限于毫秒级、无IO、不查表、不调函数的操作：比如自动设置 NEW.updated_at = NOW()、NEW.version = OLD.version + 1、或简单 CASE WHEN 赋值。其余全部拆出。
- 要发短信/邮件 → 写入消息表，由独立服务消费后调 HTTP 接口
- 要更新 Redis 缓存 → 写入消息表，消费者执行
SET user:123 '{"name":"a"}'，别在触发器里连 Redis 客户端 - 要聚合统计订单金额 → 改用物化视图增量刷新，或定时任务跑
INSERT INTO daily_stats SELECT ... GROUP BY DATE(created_at) - 要校验用户余额是否充足 → 必须前置到应用层或存储过程预检，
BEFORE INSERT里查余额表就是典型自锁陷阱
异步后怎么保证最终一致性不丢数据
消息表方案本身不解决可靠性，得靠三件事兜底：消费者幂等、消息表定期归档、失败重试机制。
- 消费者处理前先
SELECT id FROM processed_log WHERE queue_id = ?判断是否已成功，避免重复执行 -
trigger_queue表按月分区（PARTITION BY RANGE (TO_DAYS(created_at))），旧分区定期DROP防爆 - 消费者每次处理完一批记录后，用
DELETE FROM trigger_queue WHERE id IN (...)删除，但必须确保删除与业务处理在同一事务中（即先更新业务表，再删队列） - 如果消费者崩溃，未处理的记录仍在表中，下次拉取继续处理；不要依赖定时任务“每分钟扫一次”，而要用长轮询或监听
binlog（如 Canal）降低延迟
最易被忽略的是：异步不是把触发器代码原样搬进消费者里就完事。你要重新评估每一步的锁范围、索引依赖、NULL 值处理——比如触发器里用 NOT IN 查用户列表，异步任务里得换成 EXISTS，否则遇到 NULL 仍会漏数据。
