在编写和维护SQL存储过程时，开发者经常遇到过程能正常执行完毕，但最终数据结果却不符合预期的情况。此时最让人头疼的并不是语法错误，而是过程内部某个局部变量在某一行被赋予了错误的值。要查清这个问题，就必须把变量在关键节点的实际内容暴露出来。本文围绕两种最常见的调试手段展开，分别是使用SELECT直接输出变量值，以及借助临时表记录变量变化轨迹，并分析它们各自适合的场景。
一、使用SELECT输出变量值
SELECT输出是最直接的调试方式。在存储过程的业务逻辑中，随时可以插入一条SELECT语句，把某个变量或者计算结果作为结果集返回。客户端工具（如SSMS、Navicat、DBeaver）会把这些SELECT结果展示出来，开发者由此观察变量在每一步的真实状态。
这种方式的优势是零成本、零侵入。不需要建任何辅助对象，只要在怀疑的地方写一行SELECT @var，就能立刻看到值。对于只跑几百行的小过程，或者只是想确认某个分支有没有进、某个赋值对不对，它非常高效。下面是一段简单的示例，在过程里用SELECT把中间变量打印出来。
CREATE PROCEDURE dbo.CalcBonus
@empId INT,
@baseSalary DECIMAL(10,2)
AS
BEGIN
DECLARE @years INT;
DECLARE @bonus DECIMAL(10,2);
SELECT @years = DATEDIFF(YEAR, hireDate, GETDATE())
FROM dbo.Employee
WHERE id = @empId;
-- 调试输出：看年份是否正确
SELECT 'debug_years' AS item, @years AS val;
SET @bonus = @baseSalary * @years * 0.1;
-- 调试输出：看最终奖金
SELECT 'debug_bonus' AS item, @bonus AS val;
SELECT @empId AS empId, @bonus AS bonus;
END
不过SELECT输出有明显短板。首先，它会向客户端返回额外的结果集，如果过程原本就要返回一个查询结果给应用程序，那么程序可能因为多出了调试结果集而报错，或者需要修改程序才能兼容。其次，当过程很长、变量很多时，满屏的debug结果集很难对应到具体步骤，排查完还得挨个删掉这些SELECT。
另外，在正式环境或并发调用中，大量SELECT调试输出还可能干扰日志采集，甚至因为结果集未消费而导致连接异常。因此它更适合本地开发阶段做快速验证，而不是系统性排错。
二、使用临时表记录变量值
临时表记录法是在存储过程开始时创建一张局部临时表（以#开头），然后在不同逻辑节点把变量名、变量值、发生时间插入进去。过程跑完之后，统一查询这张临时表，就能得到一份完整的变量变化流水账。这种方式不会向应用程序返回额外结果集，对原有业务逻辑零干扰。
它的核心思路是把调试信息“暂存”而不是“即时打印”。由于临时表只存在于当前会话，过程结束或会话断开后自动清理，不会污染业务库。下面示例演示了用临时表记录调试轨迹。
CREATE PROCEDURE dbo.CalcBonusV2
@empId INT,
@baseSalary DECIMAL(10,2)
AS
BEGIN
CREATE TABLE #debug_log (
step_no INT,
item VARCHAR(50),
val SQL_VARIANT,
log_time DATETIME DEFAULT GETDATE()
);
DECLARE @years INT;
DECLARE @bonus DECIMAL(10,2);
SELECT @years = DATEDIFF(YEAR, hireDate, GETDATE())
FROM dbo.Employee
WHERE id = @empId;
INSERT INTO #debug_log(step_no, item, val)
VALUES (1, 'years', @years);
SET @bonus = @baseSalary * @years * 0.1;
INSERT INTO #debug_log(step_no, item, val)
VALUES (2, 'bonus', @bonus);
-- 业务返回，不受调试影响
SELECT @empId AS empId, @bonus AS bonus;
-- 调试完可单独查：SELECT * FROM #debug_log ORDER BY step_no;
END
临时表法的优点是可追溯性强。每一步插入都带有step_no和时间，出问题时能清楚看到变量从哪一步开始偏离预期。它也方便多人协作，把#debug_log的查询结果贴出来，别人一眼就能看懂执行路径。缺点是稍微麻烦一点，要建表、插数据，过程写起来比一行SELECT长。
如果存储过程特别复杂，还可以在临时表里加更多信息列，比如当前分支条件、影响的行数等，相当于自己实现了一个轻量级的跟踪框架。对于长期维护的核心过程，这种投入是值得的。
三、两种方式如何选择
从干扰程度看，SELECT输出会直接改变过程对外的返回结构，在应用调用场景下风险高；临时表只在会话内留痕，业务结果集保持干净。从排查效率看，单点怀疑用SELECT更快，系统性乱值用临时表更稳。
实际工作中可以这样搭配：本地写新过程时，先用SELECT快速看几个关键变量；一旦过程交给测试或上了类生产环境，就把调试改成临时表记录，执行后单独查日志表，既不影响调用方，也能保留证据。调试完毕，临时表相关代码可以注释保留，方便下次复用，而SELECT调试行则建议彻底删掉，避免误发到生产。
| 对比维度 | SELECT输出 | 临时表记录 |
|---|---|---|
| 实现成本 | 极低，一行搞定 | 中等，需建表插数 |
| 对业务返回影响 | 有，多结果集 | 无，仅会话内 |
| 可追溯性 | 弱，易刷屏 | 强，带步骤和时间 |
| 适用阶段 | 本地快速验证 | 测试及排错复盘 |
四、补充注意事项
使用SELECT调试时，如果变量是NULL，结果集里会显示NULL，但不要误以为语句没执行。建议在输出时拼一个固定标签，如上文的'debug_years'，方便在结果里区分。使用临时表时，SQL_VARIANT类型能存各种类型变量，但查询时可用CAST转回原类型以免显示异常。
另外，在MySQL中可用CREATE TEMPORARY TABLE，在PostgreSQL可用CREATE TEMP TABLE，思路完全一致。无论哪种数据库，核心原则都是：调试动作不该改变业务语义，也不该遗留到生产代码里。养成用完即清或注释掉的习惯，存储过程才能既好调又好稳。