触发器里的UPDATE卡住却不报错，大概率是隐式锁在作祟：InnoDB不立即加锁，而是在冲突发生时才转为显式锁，导致INNODB_TRX和data_lock_waits中查不到锁记录，形成监控盲区。
触发器里的UPDATE卡住却不报错，大概率是隐式锁在作祟
MySQL的隐式锁不会出现在INNODB_TRX或data_lock_waits里，所以你查不到它——但你的UPDATE就是不动。典型场景是：一个事务刚INSERT了一行但没提交，另一个事务马上对同一主键做UPDATE，这时后者会挂起在“updating”状态，SHOW PROCESSLIST显示Time持续增长，却查不到锁等待记录。
这是因为InnoDB没立刻加锁，而是等第二个事务真正要修改时才现场判断冲突、转为显式X锁。这个“延迟加锁”阶段就是监控盲区。
- 先用
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_STATE = 'RUNNING' AND TIME_TO_SEC(NOW() - TRX_STARTED) > 60揪出长事务，尤其关注TRX_QUERY为空或只有INSERT的记录 - 再查
performance_schema.data_locks（MySQL 8.0+）或SHOW ENGINE INNODB STATUS\G里的TRANSACTIONS段，找INSERT语句后没COMMIT的线索 - 重点检查触发器是否在
BEFORE INSERT里做了SELECT ... FOR UPDATE或更新了其他表——这类操作会提前暴露锁，反而帮你定位；但若只是普通UPDATE，就容易掉进隐式锁陷阱
触发器内SQL没走索引，会让隐式锁升级成全表级阻塞
比如BEFORE INSERT ON t_order触发器里有UPDATE t_user SET last_order_time = NOW() WHERE user_id = NEW.user_id，如果t_user.user_id没索引，这条语句就会对聚簇索引逐行加X锁。此时哪怕只插一行订单，也会让后续所有对t_user的更新/查询排队——而且你从死锁日志里只看到INSERT INTO t_order，根本意识不到问题出在触发器的全表扫描上。
- 对触发器中每条
UPDATE/DELETE/SELECT FOR UPDATE单独执行EXPLAIN，重点看type是否为ALL或index、key是否为NULL - 避免在触发器里用范围条件：
WHERE created_at > DATE_SUB(NOW(), INTERVAL 1 DAY)会锁住整个时间范围的间隙，高并发下极易引发锁等待链 - 如果必须关联数据，优先冗余字段（如把
user_name存进t_order），而不是在触发器里SELECT users.name FROM users WHERE id = NEW.user_id
如何确认慢查询源头是触发器而非主SQL
SHOW ENGINE INNODB STATUS里的LATEST DETECTED DEADLOCK只会显示顶层语句，比如INSERT INTO t_order，绝不会展开触发器内部的UPDATE t_log。所以不能靠死锁日志直接定性，得靠三处线索闭环验证：
- 死锁日志中两个事务的
HOLDS THE LOCK(S)和WAITING FOR THIS LOCK TO BE GRANTED是否同时涉及触发器目标表（例如主表t_order和触发器更新的t_audit） - 应用日志里对应时间点是否有批量操作（如一次导入1000条订单），且这些操作恰好激活多个触发器（更新日志、统计、缓存三张表）
- 用
SHOW CREATE TRIGGER trigger_name检查触发器定义，确认其内部SQL是否含SELECT FOR UPDATE、未走索引的WHERE、或跨多表更新
临时禁用触发器是最快验证手段，但别在线上乱来
如果你怀疑某触发器是性能瓶颈，最直接的办法是临时禁用它，观察慢查询是否消失。但注意：DROP TRIGGER需要TRIGGER权限，且会中断业务逻辑；更安全的做法是用SET SESSION sql_log_bin = 0配合ALTER TABLE ... DISABLE KEYS（仅适用于MyISAM）不适用InnoDB。实际生产中，推荐以下路径：
- 在低峰期用
DISABLE TRIGGER（MySQL 8.0.23+支持）或改写触发器体为BEGIN END空块，再测试 - 如果触发器逻辑简单（如仅更新单字段），可考虑将逻辑前置到应用层，用事务包住主表操作+关联表更新，便于监控和超时控制
- 永远不要在触发器里调用存储过程或自定义函数——它们会隐藏执行路径，让
EXPLAIN失效，也增加隐式锁不可预测性
隐式锁本身不可见，但它的影响非常实在：它让锁等待发生在最意想不到的时刻，且排查路径必须从触发器定义、索引有效性、事务边界三者交叉验证。漏掉任何一环，都可能在日志里看到“一切正常”，而业务早已卡死。
