旧版存储过程性能瓶颈主要源于执行计划复用失效、隐式类型转换、游标滥用和缺失架构限定；应改用sp_executesql参数化、白名单校验动态表名、SET NOCOUNT ON、补全Schema（如dbo.Orders）、用集合操作替代游标及避免WHERE子句中对字段使用函数。
直接结论：旧版存储过程性能瓶颈大多出在执行计划复用失效、隐式类型转换、游标滥用和缺失架构限定上，不是重写逻辑，而是精准替换四类模式。
避免 exec 拼接SQL导致执行计划无法复用
旧过程里常见 EXEC('SELECT * FROM '+ @table_name) 这类写法，每次拼出的字符串不同，SQL Server 就生成新执行计划，缓存浪费严重，还容易被注入。
- 改用
sp_executesql+ 参数化：把变量值作为参数传入，而非拼进SQL字符串 - 确保所有参数类型与目标列严格一致，比如
@id INT对应id INT，别用@id VARCHAR(10)再转 - 如果必须动态表名，先校验白名单（如
CASE WHEN @table_name IN ('Orders','Customers') THEN @table_name ELSE THROW...），再拼接
用 SET NOCOUNT ON 和显式 Schema 消除隐性开销
没加 SET NOCOUNT ON 时，每条 UPDATE 或 INSERT 都额外返回 “X 行受影响”，这些消息走网络、占带宽、干扰客户端解析结果集；不写 dbo.TableName 而只写 TableName，SQL Server 得先查当前用户默认 Schema，再查 dbo，还可能因权限触发重新编译。
- 所有存储过程开头加
SET NOCOUNT ON，结尾不用关（它只对当前批生效） - 所有对象引用补全 Schema，
SELECT * FROM dbo.Orders，不是SELECT * FROM Orders - 检查
sys.dm_exec_query_stats中该过程的total_logical_reads和execution_count比值，若远高于同类过程，大概率是隐式编译或低效计划在反复执行
替换游标为集合操作，尤其注意 WHERE 条件中的函数
游标本质是逐行处理，10万行 = 10万次循环 + 10万次表扫描；而 UPDATE ... FROM 或 MERGE 是单次集合操作。更隐蔽的是 WHERE YEAR(OrderDate) = 2023 这种写法——它让索引失效，强制全表扫描。
- 用
UPDATE t SET status = 'processed' FROM Orders t INNER JOIN #batch_ids b ON t.id = b.id替代游标遍历 - 日期范围改写为
WHERE OrderDate >= '20230101' AND OrderDate ，确保能走索引 - 字符串匹配避免
LIKE '%abc%'开头通配，改用全文索引或倒排结构，否则必扫全表
内存优化表变量仅在本机编译存储过程中有效
看到“内存优化”就以为能加速任意过程？错。普通解释型存储过程中声明 DECLARE @t dbo.tvp_session_data，只是多了一层类型检查，执行路径仍是传统引擎，反而慢。
- 只在真正需要极致性能且逻辑固定的场景，才用
CREATE PROCEDURE ... WITH NATIVE_COMPILATION, SCHEMABINDING - 这类过程只能访问内存优化表、不能访问磁盘表，也不能用
GETDATE()等非确定函数 - 对应表变量类型必须提前用
CREATE TYPE定义，且bucket_count要按实际唯一键数量设（例如预期 5000 行，填 8000–10000） - 临时中间结果一律用
DURABILITY = SCHEMA_ONLY，别误用SCHEMA_AND_DATA，后者会写日志、占持久内存
重构不是追求语法新潮，而是盯住执行计划是否稳定复用、IO 是否真实下降、CPU 时间是否集中在计算而非解析上。最容易被忽略的，是那些没报错、但让 SQL Server 不得不反复编译或放弃索引的“温和陷阱”。
