MySQL 8.0 存储过程调试需主动显性化执行流：用SELECT打点须防多结果集报错，临时表日志需权限与显式查询，游标必须FETCH置循环末尾并立即检查，字符集、命名冲突、浮点比较等运行时陷阱易致逻辑崩坏。
MySQL 8.0 存储过程没有断点、没有 PRINT、不返回中间变量快照——所谓“调试”，本质是把隐式执行流显性化。你得主动把状态“推出来”，而不是等它“吐出来”。
用 SELECT 打点输出时，为什么客户端收不到或报错？
因为每条 SELECT 'debug: x=' + @x; 都生成一个独立结果集，而多数应用代码（如 Python 的 cursor.execute()）只预期单结果集，遇到第二个就抛 InterfaceError: No result set to fetch from 或静默截断。
- 仅在支持多结果集的环境安全使用：MySQL CLI、MySQL Workbench 的「Execute Statement」（不是「Execute Current Statement」）
- 必须显式拼接变量：
SELECT CONCAT('i=', i, ', total=', @sum);，否则SELECT @sum;遇到NULL整行不显示 - 严禁写在
SELECT ... INTO前面：否则INTO会捕获调试语句的结果，触发ERROR 1172 (42000): Result consisted of more than one row - 若必须用于应用调用，改用临时表方案（见下一条），或加
SET group_concat_max_len = 1048576;后用SELECT GROUP_CONCAT(...)合并成单行
用临时表记录执行轨迹，为什么建表失败或日志为空？
常见原因是权限缺失或作用域错配：CREATE TEMPORARY TABLE 需要 CREATE TEMPORARY TABLES 权限，且临时表只对当前连接可见——并发调用时不会混，但若过程被 CALL 多次又没清理，可能因重复建表报错。
- 开头加
CREATE TEMPORARY TABLE IF NOT EXISTS debug_log (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP, msg TEXT); - 关键节点插日志：
INSERT INTO debug_log(msg) VALUES (CONCAT('loop start, i=', i)); - 结尾统一查：
SELECT * FROM debug_log ORDER BY ts;，别漏这句，否则你看不到任何东西 - 若报
ERROR 1142 (42000): CREATE command denied，联系 DBA 授予GRANT CREATE TEMPORARY TABLES ON *.* TO 'user'@'%';
DECLARE CONTINUE HANDLER FOR NOT FOUND 为什么总多执行一轮？
这是游标最经典的逻辑陷阱：FETCH 触发 NOT FOUND 后，HANDLER 只置标志位，但循环体（WHILE 或 REPEAT）并未立即退出，而是继续跑完本轮，导致变量被覆盖为 NULL，甚至引发 ERROR 1329。
- 标准写法必须把 FETCH 放在循环体**末尾**，并在其后立刻检查：
read_loop: LOOP FETCH cur INTO @id, @name; IF done THEN LEAVE read_loop; END IF; -- 处理逻辑放这里 END LOOP; - 千万别写成
WHILE NOT done DO FETCH ... END WHILE：因为done是上一轮 FETCH 的结果，判断和 FETCH 不同步 - 务必显式
CLOSE cur;，否则内存不释放，performance_schema.memory_summary_global_by_event_name中memory/sql/sp_head::main_mem_root会持续上涨
中文乱码、参数名冲突、浮点比较失效——这些不是语法错误，是运行时逻辑崩坏
它们不会让存储过程创建失败，却会让结果彻底不可信：中文变问号、WHERE id = p_id 永远不匹配、IF price = 99.99 总是跳过 ELSE 分支。
- 创建前必须执行
SET NAMES utf8mb4;，否则过程体内的中文字符串（含注释、SELECT '成功'）已被损坏，重启服务也救不回 - 参数/变量名别和列名同名：
DELETE FROM orders WHERE id = id;实际变成WHERE 1=1；统一加前缀，如p_id、l_total - 浮点比较必须用误差范围：
IF ABS(price - 99.99) ，直接 <code>=几乎必错 - 子查询别塞进 IF 条件：
IF (SELECT COUNT(*) FROM log WHERE order_id = p_id) > 0会反复执行；应先SELECT COUNT(*) INTO @cnt FROM log WHERE order_id = p_id;再判断
真正难的不是写对语法，而是意识到 MySQL 存储过程的“状态”是瞬时的、封闭的、无反射能力的——所有调试动作都得在它发生前埋点，在它消失前截流。一旦忽略 CLOSE、SET NAMES 或游标退出时机，问题就会从“逻辑错”滑向“内存涨”“连接卡”“字符烂”，而错误日志里往往只有一行模糊的 ERROR 1064 或空响应。
