MySQL触发器不会递归调用，所谓“崩溃”实为sp_head::main_mem_root堆内存持续堆积导致OOM；根源是table_open_cache_instances默认值16放大289+触发器的重复加载，单实例占几十KiB，总量超GB级。
MySQL 触发器根本不会无限递归——所谓“递归崩溃”实际是 sp_head::main_mem_root 内存持续堆积导致 OOM，根源在 table_open_cache_instances 配置和触发器数量。
为什么查不到“递归调用栈”，却会内存暴涨？
MySQL 明确禁止触发器内再触发其他触发器（语句级嵌套），CREATE TRIGGER 也不会生成调用链。但每个触发器定义都会编译为一个 sp_head 实例，挂在线程的 main_mem_root 上，且不随语句结束释放。当 table_open_cache_instances 值较大（如默认 16）时：
- 每次打开带触发器的表，MySQL 把该表所有触发器复制到每个 cache instance 中
- 289 个触发器 × 16 个 instance = 近 4600 个
sp_head实例常驻内存 - 每个实例含解析树、参数绑定等，单个占几十 KiB，总量轻松突破 GB 级
- 这不是栈溢出，而是堆内存持续增长 →
memory/sql/sp_head::main_mem_root占用飙升 → OOM kill
快速定位是否是触发器引发的内存问题
别猜，直接查内存视图和对象数量：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 确认 performance_schema 开启内存监控：
SELECT @@performance_schema;，若为OFF，需在my.cnf加performance-schema-instrument = 'memory/% = COUNTED'并重启 - 查内存大户：
SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes ORDER BY current_alloc DESC LIMIT 5;，若memory/sql/sp_head::main_mem_root排第一且值 >500MiB，基本锁定 - 查触发器总数：
SELECT COUNT(*) FROM information_schema.TRIGGERS;，超 200 就要警惕 - 查存储程序总量：
SELECT COUNT(*) FROM mysql.proc WHERE db NOT IN ('mysql','sys');
必须立即执行的三项修复操作
这不是 SQL 优化问题，是服务层资源治理问题：
- 立即将
table_open_cache_instances = 1：在my.cnf的[mysqld]段添加，重启生效；值为 1 时，触发器只加载一次，内存占用可降 90%+ - 降低
thread_stack反而更安全：默认 256K 足够，设太高（如 2M）可能掩盖真实内存泄漏，且对sp_head无缓解作用 - 批量清理冗余触发器：
DROP TRIGGER IF EXISTS xxx;，优先删掉历史测试、已下线功能、日志审计类低价值触发器；保留核心业务强一致性保障的那几个
真正危险的不是“递归深度”，而是大量触发器 + 高并发 + 默认 cache 分区数共同放大内存驻留量。一旦 sp_head::main_mem_root 占用超过 1GB，就说明系统已在临界点——这时候再看慢查询或锁等待，都是治标不治本。
