调试SQL Server存储过程变量首选SELECT而非PRINT，因其输出为结果集、支持多变量对比、无长度限制；若需持久化则用本地临时表#debug_log；动态SQL中外部变量不可见，须用sp_executesql传参。
怎么在SQL Server存储过程中实时看变量值
直接用 SELECT @var_name 最快，但只对当前连接可见，且不能在所有执行路径里都起作用——比如遇到 RETURN 提前退出时，后面的 SELECT 就不会执行。
常见错误现象：在 IF 分支里加了 SELECT @x，结果没看到输出，其实是分支根本没进，或者客户端（如 SSMS）默认关闭了“结果集”显示。
- SSMS 中确保「查询」→「查询选项」→「结果」→「网格」或「文本」已启用
- 避免在事务回滚后、
RETURN后、或TRY...CATCH的CATCH块末尾盲目加SELECT，容易误判执行位置 - 若变量是
XML或TEXT类型，SELECT可能截断，改用PRINT CAST(@xml_var AS NVARCHAR(MAX))
为什么不用 PRINT 而选 SELECT 输出变量
PRINT 输出走消息栏，异步、无序、长度上限 8000 字符，还不能带列名；SELECT 输出是结果集，带类型、可复制、支持多列对比，调试时一眼能看出变量和预期是否一致。
使用场景：想同时比对 @start_time、@rowcount、@status 三个值？一行 SELECT @start_time, @rowcount, @status 比三次 PRINT 清晰得多。
-
PRINT在长循环里会严重拖慢执行（每条都触发客户端消息处理） -
SELECT在 SSMS 中默认显示为网格，列名就是变量名，无需额外注释 - 注意：如果存储过程被其他 SP 调用且调用方忽略结果集，
SELECT输出会被吞掉——这时得靠临时表兜底
用临时表记录中间变量值以便回溯
当需要跨多个步骤、多次执行、或事后分析时，SELECT 太“瞬时”，必须落盘。用本地临时表 #debug_log 是最轻量可靠的方式。
关键点：必须在存储过程开头就 CREATE TABLE #debug_log，否则后续 INSERT 可能因作用域问题失败；字段类型要预留足够长度，比如 value_text NVARCHAR(4000)。
- 插入时统一用
INSERT INTO #debug_log VALUES (GETDATE(), 'step_2', 'user_id', CAST(@uid AS NVARCHAR(20)))，别省略CAST，避免隐式转换失败 - 不要用全局临时表
##debug，并发执行时数据会混 - 结尾加
IF OBJECT_ID('tempdb..#debug_log') IS NOT NULL SELECT * FROM #debug_log，方便一次性查看全链路
SELECT 输出在不同客户端的行为差异
SSMS 默认接收结果集，但 SQLCMD、Azure Data Studio、或应用程序（如 C# 的 SqlCommand.ExecuteReader）可能默认跳过非主结果集——也就是你插在中间的调试 SELECT 很可能被忽略。
性能影响很小，但兼容性风险真实存在：一个在 SSMS 里跑通的调试逻辑，换到应用里就“静默失效”。
- Java/JDBC 需设置
statement.execute()后反复调用getMoreResults() - Python/pyodbc 要用
cursor.nextset()主动跳转到下一个结果集 - 真正稳定的调试方式只有两种：写入
#debug_log表，或用 SQL Server Profiler 捕获RPC:Completed事件里的参数值
调试存储过程变量，最易被忽略的是执行上下文切换——比如你在动态 SQL 里 EXEC('SELECT @x')，这个 @x 根本访问不到外部变量，必须拼成字符串或改用 sp_executesql 配合参数。
