SQL 存储过程的创建与调用本身不难，但性能差异往往出现在细节设计和执行方式上。关键不是“写出来”，而是让数据库高效解析、缓存并复用执行计划。
避免在存储过程中拼接动态 SQL
动态拼接（如 EXEC('SELECT * FROM '+@table)）会强制每次重新编译，跳过执行计划缓存，还可能引发注入风险。除非确实需要运行时决定表名或列名，否则优先用静态 SQL + 参数化条件。
- 用 IF/ELSE 或 CASE WHEN 分支处理不同逻辑路径，保持语句结构稳定
- 多条件查询可用 WHERE 1=1 AND (@param IS NULL OR col = @param) 模式，SQL Server 优化器能较好跳过无效判断
- 真需动态表名时，限制输入范围（如白名单校验），再拼接，且加 sp_executesql 替代 EXEC，支持参数化
显式指定 SET 选项以稳定执行计划
某些 SET 选项（如 ANSI_NULLS、QUOTED_IDENTIFIER）会影响执行计划是否被复用。若创建时为 ON，而调用时为 OFF，SQL Server 会视为不同过程，拒绝复用缓存。
- 创建存储过程前，统一加上 SET ANSI_NULLS ON; SET QUOTED_IDENTIFIER ON;
- 避免在过程中反复切换 SET 值；如必须（如临时兼容旧逻辑），应在开头固定设置并注释原因
- 可通过 sys.dm_exec_cached_plans 和 sys.dm_exec_plan_attributes 查看缓存计划的 SET 属性是否一致
合理使用参数嗅探控制策略
SQL Server 默认基于首次传入参数生成执行计划，若该值极偏（如查 1 条 vs 查 100 万条），后续调用可能因复用低效计划而变慢。
- 对参数取值跨度大的查询，在关键 WHERE 子句后加 OPTION (RECOMPILE)，让每次编译适配当前值（适合 OLTP 短查询）
- 用局部变量赋值参数（如 DECLARE @local_id = @input_id），切断参数嗅探，让优化器按统计信息估算（适合中等稳定性场景）
- SQL Server 2016+ 可启用 QUERY_OPTIMIZER_HOTFIXES 或使用 USE HINT('OPTIMIZE FOR UNKNOWN')
调用端减少隐式转换与连接开销
存储过程快，不代表调用就快。客户端行为常成为瓶颈源头。
- 用 sp_executesql 调用而非直接 EXEC，支持参数化，避免重复编译
- 检查参数类型是否与过程定义完全一致（如 C# 的 int 对应 SQL 的 INT，而非 BIGINT），防止隐式转换导致索引失效
- 避免在循环内频繁调用单行存储过程；批量操作尽量改写为集合操作，或通过表值参数（TVP）一次传入多行
不复杂但容易忽略：一个存储过程是否高效，70% 取决于它怎么被写，30% 取决于它怎么被调。从定义到调用，每层都留心执行上下文与数据流的真实路径。
