先查performance_schema.memory_summary_global_by_event_name中memory/sql/sp_head::main_mem_root是否超1GB，再结合SHOW PROCESSLIST找含DECLARE CURSOR且状态为Sending data的连接；必须显式CLOSE游标并配置异常处理器，否则内存不释放。
怎么看存储过程有没有吃内存的隐患
MySQL 8.0 不会报“语法溢出”，但会因游标、大结果集或未释放资源，让 memory/sql/sp_head::main_mem_root 内存持续上涨，最终触发 OOM。真正要查的不是语法对不对，而是它会不会悄悄把内存吃光。
先执行这条语句确认风险水位：
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';
如果返回值 >1GB，尤其远超 innodb_buffer_pool_size，基本可以断定是存储过程（或触发器）在后台累积内存。
- 确保
performance_schema已启用：检查performance_schema_instrument变量是否包含memory/% = COUNTED - 别只看总量——配合
SHOW PROCESSLIST找出状态为Sending data或executing且 SQL 含DECLARE CURSOR的连接 - 临时表、大
SELECT ... INTO @var、嵌套循环中反复FETCH都会往这个内存区里堆数据，不释放
游标没关是最大雷点
MySQL 存储过程退出时不会自动释放 sp_head::main_mem_root，哪怕你用 LEAVE 跳出循环，只要没显式 CLOSE cursor_name，这块内存就一直挂着。
- 每个
DECLARE CURSOR后必须配对写CLOSE cursor_name，且放在过程末尾的END前 - 必须加异常处理器：
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN CLOSE cursor_name; LEAVE proc_label; END; - 如果游标在
BEGIN...END块内声明，CLOSE也得在同级块里执行，跨块无效 - 避免单次
FETCH拉太多行——比如SELECT * FROM huge_table进游标，一行缓存就可能占几 KB，十万行就是几百 MB
升级后语法兼容性怎么快速过一遍
MySQL 8.0 移除了模糊 GROUP BY、禁用非标准时间类型格式（如带 5.5 binary format 的列），这些不会直接报“内存溢出”，但会导致存储过程执行失败，间接引发重试风暴或连接堆积，加剧内存压力。
- 用
SHOW CREATE PROCEDURE proc_name抽出定义，人工扫一遍是否有GROUP BY列不在SELECT中、是否用了已弃用的函数（如OLD_PASSWORD()） - 查旧时间格式残留：
SELECT table_schema,table_name,column_name,column_type FROM information_schema.columns WHERE column_type LIKE '%5.5 binary format%';，有则需ALTER TABLE tbl FORCE - 别依赖
mysqlcheck --check-upgrade全检——它不扫描存储过程体内的 SQL，只能靠人眼或正则匹配关键模式
调试时埋日志比猜错误更可靠
MySQL 没有断点调试器，SHOW WARNINGS 又常只报最后一句错，真出问题时，靠日志定位比反复改代码快得多。
- 建个轻量
debug_log表，字段至少含log_time DATETIME、message VARCHAR(255)、value_info TEXT - 在游标
OPEN前、每次FETCH后、CLOSE前都插一条记录，比如：INSERT INTO debug_log(message, value_info) VALUES ('fetch loop', CONCAT('row_count=', @row_count)); - 如果发现日志停在某次
FETCH后不再前进，基本就是那行数据触发了隐式转换或 NULL 处理异常，而不是内存不够
最易被忽略的是：游标关闭逻辑只写了主路径，没覆盖所有异常分支；还有人以为“过程结束自动清理”，但在 MySQL 5.7/8.0 中这从来不是事实。
