如何排查并解决MySQL存储过程中因大型游标导致的内存溢出报错问题？

本文共计958个文字，预计阅读时间需要4分钟。

执行包含大量游标的存储过程时，MySQL 进程、RSS 内存持续上涨、响应变慢，最终可能被系统的 OOM Killer 杀死。执行杀进程命令后，如 `mesg` 显示类似 `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 —— 所以第一步永远是确认查询是否真的必要、是否可加条件过滤。