MySQL存储过程调试不能直接用SELECT输出，因其依赖客户端多结果集支持且日志不持久；必须写入InnoDB日志表，含id、proc_name、step、data、created_at五字段，配合trace_id实现可追溯、防注入、事务独立的日志记录。
为什么不能直接用 SELECT 在存储过程中调试
MySQL 存储过程里写 SELECT 'debug:', @var 看似简单，但实际会失败——除非调用方显式支持多结果集（比如某些客户端或驱动配置了 multi_statements=1），否则会报错 Commands out of sync; you can't run this command now。更麻烦的是，这种输出无法留存，一刷就丢，根本没法回溯分支跳转或循环迭代中的状态变化。
真正可行的路径只有一条：把关键点写进数据库表。不是临时表，不是内存表，必须是普通 InnoDB 表，保证事务中也能持久化（哪怕你 ROLLBACK，日志也已落盘）。
如何设计轻量但够用的日志记录表
不需要字段堆砌，4 个核心字段足矣，兼顾可读性与低侵入性：
-
id：自增主键，方便按时间排序 -
proc_name：VARCHAR(64)，存当前存储过程名，便于区分多个过程混跑 -
step：VARCHAR(128)，标记逻辑位置，比如"before_insert_loop"或"after_validation_check" -
data：JSON类型（MySQL 5.7+），存变量快照，如JSON_OBJECT('user_id', @uid, 'status', @stat) -
created_at：TIMESTAMP DEFAULT CURRENT_TIMESTAMP，自动记录时间
建表语句示例：
CREATE TABLE sp_debug_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, proc_name VARCHAR(64) NOT NULL, step VARCHAR(128) NOT NULL, data JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB;
在存储过程中插入日志的正确姿势
别用 INSERT ... VALUES 拼接字符串——容易被 SQL 注入或 JSON 格式破坏；也别在循环里频繁 INSERT——性能会断崖下跌。稳妥做法是：
- 用
INSERT INTO ... SET语法，清晰且防注入风险 - 对敏感值统一用
JSON_OBJECT()或JSON_ARRAY()封装，避免引号嵌套问题 - 如果日志量大（比如每轮循环都记），加个条件开关：
IF @debug_mode = 1 THEN INSERT ... END IF; - 注意事务隔离：日志写入独立于主逻辑事务，即使主事务回滚，日志仍存在
示例片段：
SET @debug_mode = 1;
-- ...
IF @debug_mode THEN
INSERT INTO sp_debug_log SET
proc_name = 'sp_process_order',
step = 'loop_start',
data = JSON_OBJECT('order_id', @oid, 'retry_count', @retry);
END IF;
怎么快速定位某次执行的完整轨迹
单靠 SELECT * FROM sp_debug_log ORDER BY id DESC LIMIT 100 很难聚焦。真实调试时，你需要两个锚点：
- 在存储过程开头生成唯一追踪 ID：
SET @trace_id = UUID_SHORT();，然后所有日志都带上它（加个trace_id字段，类型BIGINT） - 在调用前手动记下这个 ID，或者用
SELECT @trace_id;立即查看 - 后续查日志只需：
SELECT * FROM sp_debug_log WHERE trace_id = 9238472394723947239 ORDER BY created_at;
额外提示：别忘了定期清理日志表，加个事件或脚本，比如保留最近 7 天：DELETE FROM sp_debug_log WHERE created_at
最常被忽略的一点：日志表本身没有索引，WHERE proc_name = ... AND created_at > ... 查询会全表扫。上线前至少加一个复合索引：ALTER TABLE sp_debug_log ADD INDEX idx_proc_time (proc_name, created_at);
