必须用中间表而非SELECT输出调试信息，因为SELECT与业务结果共享响应通道，易被吞掉或截断，且客户端可能静默丢弃；中间表可持久化、排序、加时间戳和上下文，支持并发隔离与完整链路追踪。
MySQL 没有原生断点调试器，复杂存储过程必须靠中间表记录变量+执行路径来定位问题。 直接在 SELECT 里输出变量看似快，但一遇到循环、嵌套 IF 或多分支逻辑，结果集混杂、顺序难对、还可能被客户端截断——真正可靠的调试方式，是把关键状态写进一张专用日志表。
为什么非得用中间表，而不是 SELECT 输出？
因为 SELECT 输出本质是返回结果集，它和存储过程真正的业务结果共享同一个响应通道。一旦过程本身要 SELECT 返回数据给应用，你的调试信息就会被吞掉或错位；更麻烦的是，某些客户端（比如某些 JDBC 驱动、Navicat 的部分模式）会静默丢弃额外的结果集，你根本看不到输出。
-
SELECT适合单次、线性、无返回值的快速验证，比如刚写完一个简单赋值就查一下@var - 中间表能持久化、可排序、可加时间戳、可带上下文（如
proc_name、step_desc），尤其适合长时间运行、含循环/异常处理的存储过程 - 写表操作本身不影响主流程返回值，也不依赖客户端行为
如何建一张靠谱的调试日志表？
别用 TEMPORARY TABLE —— 它只在当前会话有效，而很多调试场景需要复现失败路径，甚至跨会话比对。应该建一张永久表，并预留扩展字段：
CREATE TABLE debug_log ( id BIGINT AUTO_INCREMENT PRIMARY KEY, proc_name VARCHAR(64) NOT NULL, step_desc VARCHAR(255) NOT NULL, var_values TEXT, created_at TIMESTAMP(3) DEFAULT CURRENT_TIMESTAMP(3), exec_id VARCHAR(32) DEFAULT NULL );
-
exec_id字段很重要：每次调用存储过程前生成唯一 ID（如UUID()），能把一次完整执行的所有日志串起来，避免并发调用时日志混杂 -
TIMESTAMP(3)提供毫秒级精度，能看清循环内各次迭代的时序 -
var_values用TEXT类型，方便拼接多个变量，例如：CONCAT('counter=', counter, '; total=', @total)
在存储过程中怎么插日志才不干扰主逻辑？
不要在每个 IF 分支末尾都手动写 INSERT INTO debug_log —— 容易漏、难维护。推荐封装成一个“伪过程”（实际是带参数的 INSERT 语句），并统一前置声明：
-- 在存储过程 BEGIN 后第一行就声明 exec_id
DECLARE v_exec_id VARCHAR(32) DEFAULT UUID();
<p>-- 封装日志插入（直接写 INSERT，不是 CALL 存储过程，避免递归）
INSERT INTO debug_log (proc_name, step_desc, var_values, exec_id)
VALUES ('my_complex_proc', '进入主逻辑', CONCAT('input_id=', p_id), v_exec_id);</p><p>IF p_id IS NULL THEN
INSERT INTO debug_log (proc_name, step_desc, var_values, exec_id)
VALUES ('my_complex_proc', '参数校验失败', 'p_id 为空', v_exec_id);
LEAVE main_block;
END IF;- 所有日志都带
v_exec_id，查的时候加WHERE exec_id = 'xxx'就能捞出整条链路 - 在
DECLARE EXIT HANDLER FOR SQLEXCEPTION里也插一条日志，捕获错误前的状态比错误本身更有价值 - 避免在循环体内高频写日志（比如每轮都插），可改为累计到字符串变量，循环结束后一次性插入
查日志时最容易忽略的三个细节
建好表、插进去只是第一步，查不准照样白搭：
- 别只用
SELECT * FROM debug_log ORDER BY id DESC LIMIT 20——id是自增主键，不代表执行时间顺序；必须用ORDER BY created_at DESC - 如果过程执行很快（毫秒级），多个
created_at可能相同，此时得依赖id或加上exec_id过滤 -
var_values里拼接中文或特殊字符时，确保表和连接的字符集一致（建议全库用utf8mb4），否则查出来是乱码，你会以为变量是空的
