MySQL 8.0升级后存储过程常见问题源于隐式行为收紧：GROUP BY需符合ONLY_FULL_GROUP_BY规则；变量必须显式初始化；SELECT ... INTO后须用ROW_COUNT()校验；游标FETCH与done检查顺序必须严格为先FETCH再判done。
MySQL 8.0 升级后 GROUP BY 报错：Expression #1 of SELECT list is not in GROUP BY clause
这是最常遇到的“逻辑错误”表象，实际不是存储过程写错了，而是 MySQL 8.0 默认启用了 sql_mode=ONLY_FULL_GROUP_BY。旧版本（5.7 及之前）默认关闭，允许 select 非聚合字段 + 非全 group by 字段混用；8.0 开启后直接报错。
实操建议：
- 先确认当前模式：
SELECT @@sql_mode;，检查是否含ONLY_FULL_GROUP_BY - 临时绕过（仅调试用）：
SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')); - 长期修复：改存储过程里的
SELECT语句，确保所有非聚合字段都出现在GROUP BY子句中，或用ANY_VALUE()显式包裹非确定性字段 - 注意：别在生产环境全局禁用
ONLY_FULL_GROUP_BY，它能暴露真实的数据歧义问题
存储过程中 IF / CASE 判断失效，变量值看起来“没变”
根本原因是 MySQL 8.0 对变量作用域和初始化行为更严格。尤其在循环（WHILE、REPEAT）内声明的变量，或未显式初始化的 DECLARE 变量，在某些分支下可能保持 NULL，而旧版本有时会隐式补默认值。
实操建议：
- 所有
DECLARE变量必须带初始值，例如：DECLARE v_total INT DEFAULT 0;，别依赖“未赋值即为 0” - 检查
IF分支是否遗漏ELSE，特别是当条件判断基于可能为NULL的字段时（NULL = 'x'永远为FALSE，不会进分支） - 在关键位置加日志输出（用
SELECT CONCAT('debug: ', v_var) AS _log;），避免只靠猜测流程 - 注意：MySQL 不支持
PRINT或DEBUG语句，SELECT是最轻量的调试手段
SELECT ... INTO 赋值失败却没报错，后续逻辑用到空值
MySQL 中 SELECT ... INTO 在查不到数据时，目标变量会被设为 NULL，且不抛异常——这在升级前后行为一致，但旧版业务代码可能恰好依赖“查不到就留原值”，而新版因变量初始化更严，导致原值被覆盖为 NULL。
实操建议：
- 每次
SELECT ... INTO后，立刻检查FOUND_ROWS()或用ROW_COUNT()判断是否查到行：IF ROW_COUNT() = 0 THEN ... - 避免把多个字段
INTO一个变量，容易漏判；拆成单字段赋值 + 单独校验更可控 - 如果业务允许缺省值，用
COALESCE()包裹查询，例如：SELECT COALESCE(SUM(amount), 0) INTO v_sum FROM ...; - 注意：
ROW_COUNT()在存储过程中返回的是上一条语句影响/查到的行数，不是全局状态，必须紧跟在SELECT ... INTO后面用
游标（CURSOR）遍历提前结束，最后一行数据丢失
典型表现是游标循环只执行了 N−1 次（N 是实际行数）。根本原因是 MySQL 8.0 对游标 NOT FOUND 异常处理更精确：当 FETCH 取到最后一条后，再 FETCH 一次才会触发 NOT FOUND，但很多旧代码在 FETCH 后立刻检查状态，导致最后一条被跳过。
实操建议：
- 标准写法必须是：先
FETCH→ 立即检查done标志 → *再* 处理数据。顺序不能反 - 声明
CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;后，务必在循环开头置done = FALSE（如果循环可重入） - 别在
FETCH前做数据处理，也别在FETCH后加额外逻辑再检查done，否则容易漏掉最后一次有效 fetch - 验证方法：在游标循环里加
SELECT CONCAT('row: ', v_id);，看输出行数是否匹配预期
真正麻烦的不是语法报错，而是那些“看起来跑通了，但结果少了一条、算错了一分、跳过了一个分支”的静默偏差。MySQL 升级后存储过程的问题，八成出在隐式行为收紧——别急着改逻辑，先盯住变量初始化、GROUP BY 合规性、FETCH 和 done 的时序这三处。
