触发器导致事务变长，SHOW PROCESSLIST无法显示其内部SQL，需通过INNODB_TRX和data_lock_waits定位；禁用触发器（如重命名表）可快速验证根因；修复方向是将非核心逻辑移出事务边界，改用异步处理。
触发器让事务变长，但SHOW PROCESSLIST只显示主SQL
你看到的 Updating 或 Waiting for table metadata lock 状态，大概率不是主 SQL 本身慢，而是它激活的触发器在后台卡着。MySQL 的 SHOW PROCESSLIST 只显示客户端发起的语句，触发器内执行的 UPDATE audit_log SET status = 'done' 完全不会出现在 Info 列里——它被归入父事务，锁、等待、耗时全算在主语句头上。
真正有效的线索藏在 INFORMATION_SCHEMA.INNODB_TRX 中：TRX_STARTED 时间远早于你执行命令的时间，TRX_STATE 是 RUNNING 且持续增长，TRX_QUERY 却只显示原始 INSERT INTO orders。这时候基本可以断定：触发器逻辑正在同步执行，且没走完。
- 用
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_STARTED 快速筛出“可疑长事务” - 结合
SELECT * FROM performance_schema.data_lock_waits查等待链，若BLOCKING_ENGINE_TRANSACTION_ID对应的事务在INNODB_TRX里查不到TRX_QUERY，说明它已跑完主 SQL，正卡在触发器里 - 别信
max_execution_time——它对触发器内任何语句都无效，设了也白设
禁用触发器验证比读代码快十倍
别花时间逐行 review 触发器定义，先做最小干预验证。目标是确认“是不是它导致事务拖长”，而不是“它哪里写错了”。
- MySQL 不支持运行时禁用，但可用表重命名绕过：
RENAME TABLE orders TO orders_off, orders_backup TO orders（提前建好空表orders_backup），再执行原操作。如果耗时从 2.8s 降到 17ms，锁定触发器为根因 - SQL Server 直接
DISABLE TRIGGER trg_orders_audit ON orders，验证完用ENABLE TRIGGER恢复 - 禁用后务必检查业务一致性：审计日志是否断档、下游系统是否收不到变更事件
触发器内哪些操作必然拉长事务生命周期
只要触发器里出现以下任意一种，事务就不可能短——它把本该异步、可丢弃的操作，硬塞进了强一致、必须成功、不能中断的主路径。
-
SELECT * FROM huge_log_table WHERE created_at > DATE_SUB(NOW(), INTERVAL 7 DAY)：没索引的范围扫描，每行都可能加间隙锁，锁持有时间与扫描行数正相关 -
UPDATE stats_table SET total = (SELECT SUM(amount) FROM orders WHERE user_id = NEW.user_id)：N 行插入 → N 次子查询 → N 次全表扫描 -
CALL sp_send_notification或任何外部依赖：事务停在数据库层等 HTTP 响应，锁一直挂着 -
INSERT INTO notify_queue SELECT ... FROM inserted：看似轻量，但批量插入时会生成巨量 binlog event，主从延迟直接飙升
修复不是删掉触发器，而是把它移出事务边界
真正的修复不是“怎么让触发器跑得更快”，而是“让它根本不在主事务里跑”。高频写入表上加触发器，等于给每条 DML 绑上一个不可控的定时炸弹。
- 审计类逻辑（如记录变更时间、操作人）可保留在
BEFORE INSERT/UPDATE，但仅限单行赋值，不查表、不调过程 - 统计、通知、日志聚合等非核心副作用，一律改用应用层异步队列（如 Kafka + 消费者服务）或数据库端的延迟任务（MySQL 8.0+ 的
EVENT，但需严格控制执行窗口） - 若必须数据库内处理，用
INSERT ... SELECT替代逐行触发，把多行合并为一次集合操作；同时确保所有WHERE条件字段都有覆盖索引 - 所有触发器内的字符串比较必须显式类型一致：
WHERE device_id = '123'，而非= 123——隐式转换不仅失效索引，更会导致误匹配，放大锁影响范围
复杂点在于：很多触发器问题在低并发测试环境完全不暴露，只有上线后遇到真实数据分布（带前导零、字母后缀、空格）和流量峰值才集中爆发。调试时最容易忽略的是“它确实执行了，但执行结果和你预期的完全不是一回事”。
