MySQL存储过程调试首选建临时日志表INSERT记录，或用SELECT CONCAT输出（仅开发环境手动调用有效）；禁用SIGNAL抛异常打日志，因其中断执行且低版本不支持；循环内应批量拼接日志再插入以提升性能。
MySQL存储过程里怎么输出调试信息
MySQL原生不支持PRINT或console.log这类直接打印语句，调试时不能“看到”中间值。最可行的路是把日志写进临时表或利用SELECT触发客户端可见输出——但后者有严格限制，仅适用于开发环境手动调用。
- 用
SELECT CONCAT('debug:', @var)能在执行CALL时让客户端（如MySQL Workbench、命令行）显示一行结果，但必须确保这不是存储过程最后一条语句（否则可能被误当返回集），且不能在事务块或函数中用 - 更稳的方式是建一张日志表：
CREATE TEMPORARY TABLE debug_log(msg TEXT, ts TIMESTAMP DEFAULT NOW())，然后在过程里反复INSERT INTO debug_log VALUES (CONCAT('step2: ', @i)) - 注意：临时表只对当前会话可见，不会污染生产环境；但若过程被多次调用，记得每次清空或加时间戳区分
为什么不能用RAISE ERROR打日志
有人试过用SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = CONCAT('log: ', @x)强行抛异常来“输出”，这确实能让消息出现在错误流里——但代价太大：它立刻中断执行，无法用于循环中的渐进式观察。
- 只要触发
SIGNAL，后续所有语句（包括ROLLBACK前的清理逻辑）全被跳过 - 客户端收到的是
ERROR 1644 (45000)，不是普通日志，监控系统容易误报 - MySQL 5.5 不支持
SIGNAL，低版本直接语法报错：ERROR 1064 (42000)
WHILE循环里怎么安全插日志不拖慢性能
在循环体里每轮都INSERT日志，看似直观，实际在万级迭代时可能让过程慢几倍——因为每次INSERT都是独立语句，触发日志刷盘和索引更新。
- 把日志先拼成大字符串：
SET @log_buf = CONCAT(@log_buf, 'i=', @i, ';');，循环结束后一次性INSERT，减少IO次数 - 避免在循环里查表、调函数、开游标——这些操作本身就有开销，再叠加油日志，延迟会指数级上升
- 上线前务必删掉所有调试用
INSERT INTO debug_log，MySQL不会自动忽略带注释的调试行，它们仍会被解析和跳过执行，但徒增parse负担
从客户端看日志的两个现实约束
即使你把日志写进了debug_log表，想实时查看也得靠人主动SELECT * FROM debug_log ORDER BY ts DESC LIMIT 10——没有自动刷新，也没有滚动日志视图。
- MySQL命令行客户端默认不显示
SELECT结果集以外的输出，所以SELECT调试法只在显式执行CALL时有效，嵌套在事件调度器或触发器里就完全不可见 - 如果过程用了
DECLARE CONTINUE HANDLER捕获异常，而你又依赖SELECT输出调试信息，要小心handler可能吞掉本该显示的结果集
调试信息不是越密越好，关键路径上留3–5个锚点就够了。真要追踪每一行，说明逻辑已经复杂到该拆函数了。
