SSMS支持存储过程交互式调试，但需同时满足权限（DEBUG权限）、配置（启用SQL Server调试选项）、环境（仅本地SQL Server，Azure SQL不可用）三重前提，缺一不可。
SQL Server Management Studio（SSMS）支持对存储过程进行交互式调试，但必须满足权限、配置和环境三重前提——缺一不可。Azure SQL 数据库或 Azure SQL 托管实例上完全不可用，本地 SQL Server 实例也需手动开启调试支持，否则点击“调试”会静默失败或报错 Cannot debug this procedure。
确保登录用户有 DEBUG 权限且连接启用了调试
没有 DEBUG 权限的账号无法启动调试器，哪怕你是 db_owner 也不行；而连接本身若未勾选“允许 SQL Server 调试”，断点会变成空心圆、F11 毫无反应。
- 执行
GRANT DEBUG ON DATABASE::[YourDB] TO [YourLogin]（或直接加到sysadmin角色） - 在 SSMS 中：工具 → 选项 → 查询执行 → SQL Server → 常规 → 勾选“允许 SQL Server 调试”
- 新建查询前，右键服务器 → 属性 → 安全性 → 确认“SQL Server 和 Windows 身份验证模式”已启用（仅 Windows 认证时调试可能受限）
- 连接字符串里不能含
ApplicationIntent=ReadOnly，否则调试器拒绝加载
在 EXEC 语句上设断点比右键“调试过程”更可靠
右键存储过程 → “调试过程”看似方便，但一旦过程带复杂默认值、输出参数或嵌套调用，对话框常无法正确解析参数类型，导致传入 NULL 或类型转换失败。直接在调用语句上设断点，能完整控制输入、复现真实调用链。
- 在新查询窗口中写
EXEC [dbo].[YourProc] @p1 = 'val1', @p2 = 123; - 鼠标单击该行左侧灰色边距，出现实心红点即为有效断点
- 不要用
EXEC YourProc ...省略架构名——如果数据库存在同名过程在不同架构下，省略会导致调试器绑定错对象 - 若过程有输出参数，必须显式声明变量接收：
DECLARE @out INT; EXEC [dbo].[YourProc] @in = 'x', @out = @out OUTPUT;
调试时局部变量和参数可实时修改，但注意作用域边界
悬停看值、在“本地”窗口改值、甚至直接在编辑器里覆盖变量内容都可行，但修改只在当前作用域生效，且不会回写到调用方变量——这点和 C# 或 Python 的引用传递直觉不同。
- F11 进入后，“本地”窗口显示所有
@param和@local_var，红色字体表示已被修改 - 修改
@name后按 F10 继续，后续INSERT用的就是新值；但若该变量是输入参数，原调用语句里的字面量（如'T-SQL Debugger Test'）不会变 - 临时表（
#temp）内容无法在“本地”窗口查看，需手动执行SELECT * FROM #temp查看快照 - 不要试图修改
@@ERROR或@@ROWCOUNT——它们是只读寄存器，赋值无效且无提示
SET NOCOUNT ON 是调试友好型写法的前提
没加 SET NOCOUNT ON 的存储过程，每条 INSERT/UPDATE/DELETE 都返回“1 行受影响”消息，这些消息会混在结果集中，导致 SSMS 调试器把它们当成实际返回结果，进而让“结果”面板错乱、断点跳转异常，甚至中断调试流。
- 所有存储过程开头第一行应为
SET NOCOUNT ON; - 需要查影响行数时，用
SELECT @@ROWCOUNT显式取值，而不是依赖消息输出 - 在 TRY...CATCH 中，
@@ROWCOUNT在 CATCH 块里仍有效，但它的值是 TRY 块最后一条语句的影响行数，不是错误发生点的行数 - SSMS 的“结果”面板里若看到一堆“命令已成功完成”或数字行，基本可以判定漏了
SET NOCOUNT ON
真正卡住调试的往往不是语法或逻辑，而是权限开关没开、NOCOUNT 没设、或者断点设在了 EXEC 之外的位置。先确认这三点，90% 的“调试不进入”问题就消除了。
