MySQL卡死或崩溃时，若SHOW PROCESSLIST显示大量线程卡在Waiting for table metadata lock或Locked，且innodb_buffer_pool_pages_dirty持续飙升、Threads_running突增归零，memory/sql/sp_head::main_mem_root超1GB，基本可锁定为触发器数量或复杂度失控所致。
触发器导致数据库卡死或崩溃的典型信号
看到 SHOW PROCESSLIST 里大量线程卡在 Waiting for table metadata lock 或 Locked，或者 innodb_buffer_pool_pages_dirty 持续飙升、Threads_running 突然冲高又归零——这些不是孤立现象，而是触发器引发锁链/内存泄漏/递归调用后的外在表现。尤其当 memory/sql/sp_head::main_mem_root 占用超过 1GB，基本可锁定是触发器数量或复杂度失控。
为什么触发器会把整个库拖垮
触发器本身不崩溃数据库，但它会放大三个底层风险：
- 锁等待链被拉长：比如
AFTER INSERT触发器再去UPDATE user_points，而该语句没走索引 → 全表加Next-Key Lock→ 阻塞所有对该表的读写 - 内存不可控增长：289 个触发器 +
table_open_cache_instances=16→ 每次表访问都复制触发器元数据到 16 个缓存分区 →sp_head::main_mem_root线性膨胀 - 隐式递归失控：AFTER UPDATE orders → 更新 users → 触发 BEFORE UPDATE users → 又更新 orders（哪怕只改一个字段）→ MySQL 报错
ERROR 1442但部分版本会静默失败，留下脏状态
必须立刻停掉的触发器行为
以下操作只要出现在触发器里，就等于在生产环境埋雷：
- 跨主业务表的 DML：比如从
orders触发器里直接UPDATE users SET balance = balance - ?—— 锁序无法统一，死锁概率翻倍 -
WHERE条件没命中主键或唯一索引：例如UPDATE config SET value = 'on' WHERE module = 'payment'，而module列无索引 → 全表 X 锁 - 调用含
SELECT FOR UPDATE或事务控制的存储过程：触发器内禁止显式事务，MySQL 会直接报错或中断执行 - 使用非确定性函数（
NOW()、UUID()、用户变量）且binlog_format = STATEMENT→ 主从不一致 + 触发器逻辑跳过
真正有效的止损和长期控制动作
不是删掉触发器就完事，得切断传播路径：
- 紧急时先禁用：运行
ALTER TRIGGER trigger_name DISABLE;（MySQL 8.0+），5.7 只能DROP TRIGGER后重建 - 查清 DEFINDER 权限：
SHOW CREATE TRIGGER t1;看DEFINER，再SHOW GRANTS FOR 'xxx'@'%';—— 缺少对日志表的INSERT权限会导致静默失败 - 把
table_open_cache_instances从默认 16 改成 1：重启生效，能砍掉 90% 的sp_head内存泄漏 - 所有触发器逻辑必须抽离到应用层异步队列：比如用 Kafka 或 Redis Stream 接收
orders变更事件，再由 worker 统一处理积分、通知、统计等副作用
触发器真正的危险点不在语法错误，而在它把本该由应用层协调的锁序、事务边界、资源调度，偷偷塞进数据库内核执行路径里——一旦出问题，连堆栈都看不到完整链条。
