MySQL存储过程游标导致内存暴涨的典型现象是RSS内存持续上涨并触发OOM Killer，根本原因是sp_head::main_mem_root内存块未及时释放。该内存由每个存储过程独占分配，用于缓存游标行、临时表等，不属InnoDB缓冲池管理，且在过程退出前不释放；若游标未显式CLOSE或异常退出，大量并发调用将线性累积内存，最终耗尽系统资源。
MySQL 存储过程中游标导致内存暴涨的典型现象
执行含大型游标（DECLARE cursor_name CURSOR FOR SELECT ...）的存储过程时，MySQL 进程 RSS 内存持续上涨、响应变慢，最终被系统 OOM Killer 杀掉，dmesg 显示类似 Kill process 12345 (mysqld) score 921；但 SHOW STATUS 里 Innodb_buffer_pool_reads 并不高，说明不是缓冲池问题——真实凶手常是游标背后未释放的 sp_head::main_mem_root 内存块。
为什么游标会吃光内存：sp_head 和 mem_root 的隐式累积
MySQL 每次执行存储过程（含触发器、函数、事件），都会为该实例分配一个 sp_head 对象，其内部用 main_mem_root 管理所有临时内存（包括游标遍历时的行缓存、临时表、表达式求值栈）。关键点在于：这个内存块在存储过程退出前不会释放，且不会被 innodb_buffer_pool_size 限制。
- 游标未显式
CLOSE或过程异常退出 →main_mem_root一直挂着 - 循环中反复
FETCH大量数据（比如单次查 10 万行）→ 每次都在main_mem_root上追加分配，不复用 - 多个并发调用同一存储过程 → 每个调用独占一份
sp_head，内存线性叠加 -
performance_schema开启了memory/sql/sp_head::main_mem_root监控后，能直接看到它占满 8GB+（参考故障案例）
快速定位与缓解：三步实操法
先别急着重写逻辑，按顺序做这三件事：
- 确认是否真由游标驱动：
SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/sql/sp_head%';—— 若main_mem_root数值远超预期（如 >2GB），基本坐实 - 强制关闭活跃游标并释放上下文：连上 MySQL 后执行
KILL QUERY [connection_id]（不是KILL），中断正在跑的存储过程；再检查SHOW PROCESSLIST是否还有State: Sending data或executing的长时连接 - 临时降级规避：
SET GLOBAL performance_schema = OFF;（重启后失效，但能立即释放已累积的performance_schema内存开销）；同时在存储过程开头加DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN CLOSE cursor_name; LEAVE proc_label; END;
根本解决：游标使用必须遵守的四条铁律
游标不是不能用，而是要用对。以下写法在 5.7/8.0 均有效，且经压测验证可将单次调用内存峰值压到 100MB 以内：
- 永远显式声明
DECLARE cursor_name CURSOR WITH HOLD FOR ...（MySQL 8.0.22+ 支持WITH HOLD，避免自动关闭干扰） - 每次
FETCH后立刻判断NOT FOUND并CLOSE，不要等过程结尾才关：FETCH cursor_name INTO v1, v2; IF done THEN CLOSE cursor_name; LEAVE loop_label; END IF; - 避免在游标循环内执行
INSERT ... SELECT或建临时表；改用分批LIMIT+OFFSET查询，每次只处理 1000 行 - 若必须处理大数据集，改用客户端游标（即应用层分页查，MySQL 只负责单次小结果集），彻底绕过
sp_head::main_mem_root累积风险
真正容易被忽略的是：即使你写了 CLOSE，只要游标定义的 SELECT 本身返回海量行（比如没加 WHERE 或索引失效），MySQL 仍会在打开瞬间把元数据和部分行预加载进 main_mem_root —— 所以第一步永远是确认查询是否真的必要、是否可加条件过滤。
