SQL 存储过程调试和日志记录不是“加个 PRINT 就完事”，关键在于让执行路径可追溯、错误可定位、状态可验证。核心思路是：用轻量级日志做过程快照，用可控断点替代盲目猜测，用结构化输出辅助分析。
分层日志：按执行阶段打点
在关键节点（如参数校验后、循环开始前、事务提交前）插入带上下文的日志记录。避免只记“开始”“结束”，要包含变量值、影响行数、时间戳：
- 用 INSERT INTO log_table 替代 PRINT——PRINT 不持久、不跨会话、难检索；日志表建议含字段：
proc_name、step_desc、params_json（用 FOR JSON AUTO 简单序列化）、rowcount、log_time - 对高频调用过程，加 日志开关参数（如
@debug_mode BIT = 0），默认关闭，调试时传 1 再写日志，避免生产环境性能损耗 - 敏感字段（如身份证、手机号）写日志前主动脱敏，用
LEFT(@id, 3) + '****' + RIGHT(@id, 4)类方式处理
可控中断：模拟断点调试逻辑
SQL Server 本身不支持交互式断点，但可通过条件阻塞+外部观察实现等效效果：
- 在怀疑出错的位置插入：
IF @debug_mode = 1 WAITFOR DELAY '00:00:05'，留出时间查sys.dm_exec_requests或 Profiler 抓当前执行堆栈 - 配合临时表存中间结果：
SELECT @var1 AS val1, @var2 AS val2 INTO #debug_snapshot，调试时直接查该表看变量状态，无需反复重跑 - 用 RAISERROR(..., 0, 1) WITH NOWAIT 强制立即输出消息（比 PRINT 更可靠），适合长过程中的进度提示
错误捕获：不只是 TRY...CATCH
TRY...CATCH 是基础，但需补充上下文才能快速归因：
- CATCH 块内必须记录
ERROR_PROCEDURE()、ERROR_LINE()、ERROR_MESSAGE()，并拼接入日志表，不要只靠 RAISERROR 向上抛 - 对可能失败的 DML 操作（如 UPDATE/DELETE），先用
@@ROWCOUNT判断是否“静默失败”（比如 WHERE 条件没命中却没报错） - 涉及游标或循环时，在循环体末尾加
IF @i % 100 = 0 INSERT INTO log_table (...) VALUES ('loop progress', @i)，防无限卡死无感知
日志归档与清理策略
日志表不清理会拖慢系统，但删太勤又丢失线索：
- 日志表按月分区（如
log_proc_202404），用SWITCH PARTITION快速归档旧数据到历史库 - 设置自动清理作业：保留最近 7 天 debug 日志、90 天 error 日志，用
DELETE TOP (10000)分批删，避免长事务锁表 - 关键业务过程的日志（如支付、结算）单独标记
is_critical = 1，永不自动清理，人工审核后归档
调试不是越详细越好，而是让每个日志条目都能回答一个具体问题：哪一步？什么输入？什么输出？哪里异常？把这四个要素固化进日志模板和调试习惯里，效率提升立竿见影。
