最拖后腿的步骤看箭头粗细和操作符右上角百分比，越大越耗资源；常见高占比操作符暴露缺失索引、隐式转换或排序问题。
怎么看执行计划里哪一步最拖后腿
直接看 SQL Server Management Studio（SSMS）里「显示实际执行计划」的图形界面，重点盯住两个视觉信号：箭头粗细和操作符右上角的百分比数字。箭头越粗、数字越大（比如占 78%），说明这一步消耗资源最多。常见高占比操作符包括 Clustered Index Scan、Table Scan、Hash Match、Sort —— 它们往往暴露了缺失索引、数据类型隐式转换或排序逻辑失控的问题。
为什么加了索引，执行计划还是走全表扫描
不是所有索引都能被用上。常见原因有：
-
WHERE条件字段没在索引键列最左侧（比如索引是(status, created_at)，但查询只用了created_at = '2024-01-01'） - 字段存在隐式转换：比如参数是
@id NVARCHAR(50)，而列定义是INT，SQL Server 会放弃索引查找转为扫描 - 统计信息过期，优化器误判行数，认为扫描比查找更“便宜”
- 查询中用了函数包裹字段，如
WHERE YEAR(order_date) = 2024，导致索引失效
执行计划里出现 CONVERT_IMPLICIT 怎么办
这是性能杀手级警告，意味着 SQL Server 在运行时偷偷做了类型转换，通常伴随索引失效和大量 CPU 消耗。查法很简单：在执行计划 XML 中搜索 CONVERT_IMPLICIT，定位到对应 Compute Scalar 或 Seek/Predicate 节点；然后回看 T-SQL，检查变量/参数/字段三者是否类型一致。例如：
DECLARE @user_id VARCHAR(10) = '123'; SELECT * FROM users WHERE id = @user_id; -- id 是 INT 类型 → 触发 CONVERT_IMPLICIT
修复方式是统一类型：DECLARE @user_id INT = 123;，或者显式转换字段端（不推荐）。
临时表和表变量在执行计划里表现差异大吗
非常大。表变量（@temp）默认没有统计信息，优化器总是预估 1 行，容易选错连接算法（比如该用哈希连接却选嵌套循环）；而临时表（#temp）有统计信息（除非加 OPTION (RECOMPILE) 强制重编译）。如果临时表数据量超过几千行，务必加索引，否则执行计划里大概率冒出 Table Scan 和 Spill to TempDB —— 后者意味着内存不够，写磁盘，速度断崖下跌。
实际调优时，最常被忽略的是「参数嗅探」和「计划缓存污染」：同一个存储过程，第一次用小数据集参数生成的计划，可能完全不适合后续大数据集调用。这时候光看单次执行计划不够，得结合 sys.dm_exec_query_stats 查历史平均逻辑读和执行次数，再决定是否加 WITH RECOMPILE 或用 OPTIMIZE FOR。
