真正起作用的注释位置只有三个：参数声明后的块注释说明业务含义、关键逻辑段前解释目的、IF/CASE分支内部阐明意图；必须用/ /而非--写长注释；参数注释需与声明对齐；缩进统一为4空格；命名须语义明确、避免保留字；动态SQL注释需注入字符串并验证。

SQL Server 存储过程中注释写在哪才真有用

注释不是写给编译器看的，是写给三个月后的你自己或刚接手的同事看的。在 CREATE PROCEDURE 里把注释堆在开头、堆在末尾，基本等于没写。

真正起作用的位置只有三个：/* */ 包裹的块注释放在参数声明后（说明每个 @param 的业务含义），关键逻辑段前（比如“此处计算用户7日留存，含去重与时间窗口校验”），以及 IF/CASE 分支内部（避免只看到条件却猜不出意图）。

• 别在 AS 后面空两行再写注释——人眼扫描时会跳过，等同于隐藏
• 避免用 -- 写长段落注释：SQL Server 对单行注释长度无限制，但编辑器折叠、SSMS 高亮常出问题，/* */ 更稳
• 参数注释必须和声明对齐，例如：

  CREATE PROC dbo.usp_GetOrderSummary<br>    @StartDate DATE,  /* 起始日期，含当日，格式 YYYY-MM-DD */<br>    @Status TINYINT    /* 0=全部, 1=已发货, 2=已取消 */

别让缩进暴露你的 SQL 风格混乱

SQL Server 不依赖缩进执行，但人脑靠缩进识别嵌套层级。一个 SELECT 套三层 JOIN 再加子查询，如果全顶格写，等于强迫别人手动数括号。

核心原则：每级结构换行 + 缩进 4 空格（不是 Tab），且缩进位置严格对应逻辑块边界。特别注意 WHERE、GROUP BY、ORDER BY 必须单独成行，条件之间用换行而非逗号分隔。

• FROM 和后续所有 JOIN 对齐，ON 条件缩进一层，多条件换行
• SELECT 列表每列一行，别挤在一行里用逗号连写（尤其含函数或别名时）
• CTE 的 WITH 块必须整体缩进，AS ( 后换行，) 单独成行并与 WITH 对齐

命名不规范比逻辑错更难 debug

看到 @a、@tmp1、sp_xxx 这类名字，第一反应不是查逻辑，而是翻文档或问人——这已经拖慢了 3 分钟。

存储过程名必须带业务动词前缀，如 usp_CalculateMonthlyRevenue（usp = user stored procedure），临时表用 #OrderTemp 而非 #t1，变量名直说用途：@MaxRetryCount 比 @cnt 强十倍。

• 避免 SQL Server 保留字作名：哪怕加了方括号，[order] 也比 OrderData 多一次认知负担
• 大小写保持一致：SQL Server 默认不区分，但团队统一用 PascalCase（如 @CustomerID）比全小写更易扫读
• 别用拼音缩写：如 @khmc（客户名称），换成 @CustomerName，多打 5 个字符，省下 5 分钟理解时间

动态 SQL 注释失效时怎么保命

用 EXEC(@sql) 或 sp_executesql 时，所有写在外部的注释对生成的语句完全无效。这时候注释必须“注入”到字符串里，否则等于裸奔。

安全做法是在拼接前就把注释塞进 @sql 变量，且用 /* */（-- 在字符串里容易被误截断）。同时，务必在执行前用 PRINT @sql 或 SELECT @sql AS GeneratedSQL 输出验证——很多逻辑错误其实就藏在拼出来的 SQL 里。

• 别在 EXEC('SELECT ...') 里硬写注释：字符串内单引号需转义，-- 极易因拼接顺序被吞掉
• 用 CHAR(13) + CHAR(10) 换行，保证生成 SQL 可读；纯空格缩进会被忽略，必须用真实换行符
• 如果动态部分来自参数，注释里要写死示例值，比如：/* @Status=1 → WHERE Status = 1 */

最常被忽略的点：注释里的业务规则一旦变更，代码未必同步更新。定期用 SELECT OBJECT_NAME(object_id), definition FROM sys.sql_modules WHERE definition LIKE '%// TODO%' 类似方式扫残留标记，比靠人记靠谱。