print用于快速验证中间状态，需在关键分支前输出带上下文的变量值（如'status = ' + isnull(cast(@status as varchar(10)), 'null')），避免循环内高频打印，且不可替代if+throw断言校验。
SQL Server里怎么用PRINT快速验证中间状态
PRINT不是万能的，但它在逻辑分支多、变量流转复杂的存储过程中最直接有效。关键不是“打多少”，而是“打在哪”和“打什么”。
- 别只打印变量名，比如
PRINT @status——它输出空字符串时你根本不知道是NULL还是0；改成PRINT 'status = ' + ISNULL(CAST(@status AS VARCHAR(10)), 'NULL') - 在每个IF/ELSE分支入口处都加PRINT，尤其是
IF @id IS NULL这种容易被忽略的判断前 - 避免在循环体里高频PRINT（比如每行都PRINT），会拖慢执行、刷屏难定位；改用计数器+条件触发：
IF @i % 100 = 0 PRINT 'processed '+CAST(@i AS VARCHAR)+' rows' - PRINT不会中断执行，所以它适合观察流程走向，但不能替代断言——发现值不对时还得靠
THROW停下来
SSMS调试器为什么断点不生效
不是所有环境都支持图形化调试，而且启用条件很具体。
- 必须连接到本地或局域网内的SQL Server实例（Azure SQL Database / Azure SQL Managed Instance不支持）
- 登录账户需有
sysadmin角色，或被显式授予DEBUG权限（GRANT DEBUG ON DATABASE::[YourDB] TO [user]） - 存储过程不能是加密的（
WITH ENCRYPTION），否则调试器读不到源码 - 如果使用Visual Studio调试，仅Professional及以上版本支持T-SQL调试；Community版不行
- 调试时EXEC语句必须单独一行，且前面不能有注释或空行，否则断点可能挂载失败
怎么用IF+THROW模拟断言验证逻辑结果
SQL Server没有ASSERT，但IF NOT ... THROW组合足够可靠，重点是让失败信息可追溯。
- 校验输出参数：执行后立刻查
@out_result，不要等到最后再汇总检查 - 校验影响行数：先
SELECT @@ROWCOUNT，再做内容比对；数量不对，内容就不用看了 - 校验结果集内容：把结果INSERT到临时表（如
#expected和#actual），用EXCEPT比对差异 - 错误消息里必须带期望值和实际值，例如：
THROW 50000, 'Expected status=1, got '+CAST(@actual_status AS VARCHAR), 1 - 别用
RAISERROR代替THROW——前者默认不中断后续语句，容易掩盖连锁错误
MySQL存储过程没法用SSMS调试，怎么办
MySQL官方工具链不提供断点调试能力，必须靠结构化日志+临时表回溯。
- 用
SELECT 'step 3: before update', @var1, @var2;代替PRINT——这是唯一能在客户端看到的调试输出 - 把关键中间结果存进
TEMPORARY TABLE，比如CREATE TEMPORARY TABLE _debug_step2 AS SELECT * FROM #temp_data; - 测试完立刻
DROP TEMPORARY TABLE _debug_step2;，避免残留影响下一次调用 - OUT参数要显式初始化：
SET @out_total = NULL;，否则未赋值时读出来是NULL，但你不确定是逻辑没走到，还是真为NULL - 复杂逻辑建议拆成小过程，每个只做一件事——这样调试范围更小，也方便复用校验逻辑
真正卡住人的往往不是语法错，而是某次UPDATE漏了WHERE、JOIN少写了ON条件、或者NULL参与了+运算导致整列变NULL。这些错误不会报错，只会静默产出错误数据。所以调试的核心不是“找到报错那一行”，而是“确认每一步的输出是否符合预期”。
