MySQL存储过程本身不直接报内存溢出，但大量触发器等存储程序通过memory/sql/sp_head::main_mem_root持续占用内存导致OOM。该内存区长期驻留、不随调用释放，尤其在多触发器、大table_open_cache_instances、触发器内大变量操作时飙升；可通过Performance Schema监控定位，并调小缓存实例数、禁用非必要触发器、限制查询结果集等方式缓解。
MySQL 存储过程本身不会直接报“内存溢出错误”，但大量或复杂存储过程（尤其含大触发器）会通过 memory/sql/sp_head::main_mem_root 持续吃光内存，最终触发 OOM Killer 杀掉 mysqld。
为什么存储过程会导致 OOM？看 memory/sql/sp_head::main_mem_root 占用飙升
这个内存统计项代表所有存储程序（包括存储过程、函数、触发器、事件）的执行上下文总开销。它不是单次调用就释放，而是长期驻留——尤其当：
- 表上有几十甚至上百个触发器，每次打开表都会把全部关联触发器加载进该内存区
-
table_open_cache_instances设得过大（如默认 16），导致每个 instance 都缓存一份完整的sp_head实例 - 触发器逻辑里用了
SELECT ... INTO @var或拼接超长字符串，变量内容实际也堆在main_mem_root里
典型现象：SHOW ENGINE PERFORMANCE_SCHEMA STATUS 查不到异常，但 SELECT * FROM performance_schema.memory_summary_global_by_event_name WHERE event_name LIKE 'memory/sql/sp_head%' 显示该值持续增长到数 GB。
如何快速定位是哪个存储过程/触发器在吃内存
不能只查数量，要抓活跃加载行为：
- 先确认是否开了全量内存监控：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema_instrument'，若返回'memory/% = COUNTED'，说明已开启——这是前提 - 执行
SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME = 'memory/sql/sp_head::main_mem_root'，记下当前值 - 手动触发疑似高危表的 INSERT/UPDATE（比如带复杂触发链的订单表），再查一次该值，差值就是本次触发消耗
- 配合
SELECT TRIGGER_NAME, EVENT_MANIPULATION, ACTION_STATEMENT FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'xxx'快速列出目标表所有触发器，逐个注释测试
不改业务逻辑，怎么压住 sp_head 内存增长
核心思路是减少“每次打开表时加载的触发器副本数”和“单个 sp_head 实例的体积”：
- 把
table_open_cache_instances从默认 16 改成1：加配置table_open_cache_instances = 1并重启 MySQL，可立竿见影降低main_mem_root峰值 50% 以上（实测 8GB → 3GB） - 禁用非必要触发器：
ALTER TABLE t1 DISABLE TRIGGER trig_name，比删掉安全，需要时再启用 - 避免在触发器里做
SELECT ... INTO @large_blob；改用临时表或应用层处理大结果集 - 检查
max_connections是否虚高——每个连接都可能持有自己的sp_head缓存，设为 100 比 500 更稳妥
优化查询本身对 sp_head 内存无效，但能防连锁 OOM
存储过程里如果包含 SELECT * FROM huge_table WHERE ... 这类语句，虽然不直接影响 sp_head，但会撑爆 sort_buffer_size、tmp_table_size 和线程栈，叠加 main_mem_root 就直接越界。所以必须同步收紧：
- 在存储过程中显式加
LIMIT，哪怕只是LIMIT 1000，防止意外全表扫描 - 把大结果集拆成游标分批处理：
DECLARE cur CURSOR FOR SELECT id FROM t LIMIT 1000 OFFSET 0，别一次性SELECT ... INTO赋值给变量 - 确认
innodb_buffer_pool_size没超/proc/meminfo里的MemAvailable值减去 2GB，否则根本没余量扛住其他内存上涨
真正危险的从来不是单个参数超标，而是 sp_head + buffer_pool + per-connection buffers 三者同时逼近极限——只要一个波动，OOM 就发生。
