简介SQL Server 执行计划中索引查找Index Seek为何会退化为索引扫描Index Scan这份文档以排查思路为主线面向 SQL Server 开发与运维人员梳理了导致该问题的 10 类典型场景包括隐式转换、非 SARG 谓词、谓词选择度过低、统计信息过期或失真、联接条件与索引键不匹配、排序分组需求、索引覆盖不足、高度碎片化、并行计划选择、参数嗅探及资源受限等。文档逐一结合上下文给出测试与结论并重点演示了隐式转换案例例如将 NVARCHAR 列与数值常量直接比较时执行计划会从 Index Seek 变为 Index Scan文章同时给出两种避免写法并附有用于搜索执行计划中隐式转换的 SQL 脚本。资源为 1 个 PDF 文件大小约 415KB内容结构清晰既包含理论归纳也提供可操作的优化建议。目前已有 331 人学习下载适合需要提升查询性能、排查执行计划异常的读者参考。1. 索引查找变成索引扫描优化器这笔账算错了还是本来就该扫线上一个订单查询原本毫秒级返回某天突然变成秒级。抓出执行计划一看之前的 Index Seek索引查找变成了 Index Scan索引扫描。索引没坏、数据没丢、重启也解决不了真正的问题藏在优化器算的那笔成本账里。下面按查询写法、数据统计、缓存计划三层拆开讲 SQL SERVER 里让索引查找退化回索引扫描的原因配上可直接复现的 SQL 示例讲清每类怎么识别、怎么修适合正在做慢查询优化或者被领导追问“明明加了索引为什么还是扫描”的从业者。2. 优化器怎么算账Seek 与 Scan 的成本差先对齐刚接手这类问题时我最常看到的动作是看到执行计划里出现 Index Scan反手就把责任归给“索引没建好”。其实优化器选 Scan 不是抽签而是两套成本表达式比大小之后的结果。只有先理解 Seek 和 Scan 在物理上是怎么干活的后面的排查顺序才有依据。2.1 B-Tree 两种访问方式成本构成完全不一样Index Seek 走的是从根页到中间页再到叶子页的树遍历每次只读目标键值所在的那一小段叶子页IO 模型是少量随机读。Index Scan 则是从索引或表的叶子链第一页开始顺着链接一路读完IO 模型是顺序读加预读read ahead一次能带进一大批区。同样读 1000 个页随机 IO 的物理耗时远高于顺序 IO所以优化器对 Seek 和 Scan 的成本估算从来不是按“读页数”一刀切。两条路径的成本表达式差别很大Seek 的成本由“树的高度 预计命中的页数 后续书签查找如果需要回表次数”构成Scan 的成本基本由“索引或表总页数”决定和最终返回多少行关系不大。当预估返回行数占表总行数的比例升高时Seek 的成本曲线会陡增Scan 反而显得便宜。经验上比例超过 20% 到 30% 时Scan 经常胜出这个区间受行宽、页密度、索引深度影响不是硬阈值。这也是为什么做这个问题的分析要先立一个观念Seek 变 Scan 不一定是错事。如果查询确实要读全表的四分之一行选择性这么差的谓词本来就救不回来纠结操作符名字没有意义。后面所有排查技巧本质上都是在回答“优化器算出来的这笔账依据到底可不可信”。2.2 用执行计划和 IO 统计读出“它为什么选了 Scan”打开实际执行计划直接看 Index Scan 操作符的“谓词”属性是第一步。操作符属性里如果只有 Predicate残差谓词没有 Seek Predicate说明这个谓词根本没法定位到 B-Tree 的键范围只能把相关页全读出来再过滤。如果既有 Seek Predicate 又有 Predicate说明索引只帮了一部分忙剩下的条件在叶子上过滤。搞清楚这两者的差别后面排查方向就不一样了。配合 IO 统计可以更直观。通常我会先跑一遍 SET STATISTICS IO把逻辑读记下来作为基线。逻辑读是访问的页数不受缓存影响用作前后对比比耗时更稳定。-- 打开 IO 与时间统计跑一次查询 SET NOCOUNT ON; SET STATISTICS IO ON; SET STATISTICS TIME ON; SELECT SalesOrderID, OrderDate, CustomerID, TotalDue FROM Sales.SalesOrderHeader WHERE OrderDate 2024-01-01T00:00:00 AND OrderDate 2024-02-01T00:00:00; GO SET STATISTICS IO OFF; SET STATISTICS TIME OFF;这段查询的谓词直接落在 OrderDate 列上的范围比较是 SARGable 的OrderDate 索引可以被利用。重点看消息选项卡里的 Scan count 和 logical reads如果这个结果只有几十页说明走的是 Seek如果跑出上千页甚至和整表页数差不多说明要么索引没建对要么优化器选择了扫描。消息里还会给出 CPU 和耗时但那个受机器负载影响大做对比时以 logical reads 为主。参数说明SET STATISTICS IO 的输出关键字段是 Scan count扫描次数、logical reads逻辑页访问数、physical reads从磁盘读的页数含预读。不同写法之间对比时只对比 logical reads 就能排除缓存干扰。注意把 IO 统计关掉再跑其他查询不然消息窗口会被刷屏。再看 Estimated vs Actual如果 Estimated Rows 和 Actual Rows 差出数量级问题大概率在统计信息或基数估算如果两者接近优化器算的账本来就是扫描更便宜要改的是查询写法或索引设计而不是跟优化器较劲。2.3 书签查找如何把 Seek 的账算崩还有一个让 Seek 败给 Scan 的常见中间环节是书签查找。非聚集索引只存索引键和定位器定位器在聚集索引表里是聚集索引键在堆表里是 RID。走非聚集索引 Seek 拿到定位器后如果查询要的列不在索引里得回到聚集索引或堆里取数据每次回表都是一次随机 IO。当 Seek 返回的行数一多回表次数跟着涨成本很快就超过直接扫一遍。优化器在“非聚集索引 Seek 书签查找”和“聚集索引 Scan”之间比较常常选择后者。这类退化的特征很明显执行计划里同时出现 Index Seek 和 Key Lookup/RID Lookup 两个操作符而实际走的是 Scan。应对方向通常三个把查询要的列补进非聚集索引的 INCLUDE让 Seek 自给自足调整索引键顺序让 Seek 本身命中行数变少或者在确定无法满足时接受 Scan不要硬塞提示。具体哪些做法会翻车第 5 章里会展开讲。3. 查询写法引发的退化非 SARGable 谓词、隐式转换与 OR 条件优化器能不能把谓词翻译成索引键上的范围取决于写法。下面这张表先给结论谓词里索引列保持原样是 Seek 的前提。谓词形态示例优化器的处理SARGableOrderDate 2024-01-01 AND OrderDate 2025-01-01可写入 Seek Predicates沿 B-Tree 定位非 SARGableYEAR(OrderDate) 2024无法定位键范围只能全扫后残差过滤函数在参数侧OrderDate DATEADD(year, 1, 2023-01-01)索引列没被碰Seek 可保留函数在列侧DATEADD(year, 1, OrderDate) 2024-01-01索引列被包进表达式Seek 失效3.1 函数套在索引列上Seek 条件直接失效所谓 SARGable是 Search Argument Able 的缩写意思是“这个谓词能被索引键直接利用”。索引列原样和常量/参数做比较优化器才能算出键的起点和终点。只要索引列被包进函数或表达式比如 YEAR(OrderDate)、DATEADD(day, -1, OrderDate)、列 1、LEFT(列, 3)优化器就失去了定位起点只能把所有相关页读出来逐行做一次残差过滤。这里有个容易误解的地方执行计划里 Scan 操作符的 Predicate 属性和原 SQL 条件长得一模一样看起来好像没毛病所以很多新手以为是索引丢了。其实正是由于索引列上套了函数这个谓词没法搬到 Seek Predicate 里才以残差身份挂在 Scan 后面。识别的关键就是看谓词在计划里出现在哪个位置。-- 翻车写法索引列上套 YEAR 函数 SELECT SalesOrderID, TotalDue FROM Sales.SalesOrderHeader WHERE YEAR(OrderDate) 2024; -- 修正写法范围比较索引列保持原样 SELECT SalesOrderID, TotalDue FROM Sales.SalesOrderHeader WHERE OrderDate 2024-01-01T00:00:00 AND OrderDate 2025-01-01T00:00:00;第一段的 YEAR 函数让优化器无法在 OrderDate 上构建 Seek 谓词只能把 2024 年涉及的叶子页全扫出来再过滤逻辑读通常是第二段的几十倍。第二段改成半开区间后优化器能在 B-Tree 上算出第一个大于等于 2024-01-01 的键位置直接 Seek 进入沿叶子链顺序读到 2025 年前结束IO 量大幅下降。参数说明日期范围统一写成“大于等于起点且小于下一个起点”的半开区间比 BETWEEN 更稳能避开 datetime 与 datetime2 在边界精度上的换算。如果查询条件来自应用程序先把参数在传入前转成目标类型不要写 CONVERT(列, ...) 这类把转换放在列上的写法。3.2 隐式转换VARCHAR 列遇 NVARCHAR列上多了一次 CONVERTSQL Server 的数据类型之间有隐式转换优先级规则低优先级向高优先级转换。规则不复杂VARCHAR 低于 NVARCHARINT 低于 BIGINT日期类型里 DATETIME 低于 DATETIME2。当比较发生在列和常量/参数之间SQL Server 会选择把低优先级的一方转成高优先级这个转换如果发生在索引列上Seek 就废了。最常见的一幕是应用层用 NVARCHAR 参数去查 VARCHAR 列。参数是 NVARCHAR优先级高SQL Server 就把列隐式转成 NVARCHAR 再比较。索引键上被包了一层 CONVERT_IMPLICIT本来可以精确命中的等值查询退化成了把整个索引叶子页扫一遍再逐个比较。而反过来索引列是 INT参数传的是字符串 12345字符串优先级低转换发生在参数侧索引列没被碰Seek 能保住。判断在哪一侧打开实际执行计划找 CONVERT_IMPLICIT 出现在哪个 Input 上即可。-- 场景SalesOrderNumber 列是 VARCHAR(20)参数是 NVARCHAR DECLARE OrderNumber NVARCHAR(20) NSO50001; SELECT SalesOrderID, SalesOrderNumber FROM Sales.SalesOrderHeader WHERE SalesOrderNumber OrderNumber; -- 修正参数类型与列一致 DECLARE OrderNumber2 VARCHAR(20) SO50001; SELECT SalesOrderID, SalesOrderNumber FROM Sales.SalesOrderHeader WHERE SalesOrderNumber OrderNumber2;第一段里 NSO50001 是 NVARCHAR优先级高于列SQL Server 选择把列转成 NVARCHAR。执行计划中 SalesOrderNumber 输入节点上出现 CONVERT_IMPLICIT索引查找退化成索引扫描。第二段把参数改成 VARCHAR类型匹配转换消失计划回到 Index Seek。实际的逻辑读差距在索引页较多时非常明显。参数说明如果参数来自 ORM 或接口层经常统一走 NVARCHAR这时候要看具体的列类型来决策。表列是 VARCHAR 时优先把存储过程的入参也定义为 VARCHAR如果应用层无法改有限范围内可以考虑把列改成 NVARCHAR但要提前确认磁盘空间和现有 VARCHAR 参数免得改完列换 VARCHAR 参数反过来去转换 NVARCHAR 列。JOIN 两表字段类型不一致时同理先把两边的实际数据类型查出来再定方案。3.3 OR 条件的两副面孔能展开成 Seek也能摊平成 ScanOR 条件很容易被翻车。如果 OR 的几个分支都精确匹配同一列的索引值优化器通常能把它拆成多个等值 Seek效果类似 IN 列表。比如 WHERE Status 3 OR Status 5 在 Status 有索引时可以走 Seek。但一旦 OR 分支里混入了非 SARGable 条件或者两个分支落在不同索引列上整个谓词常常没法成为连续的 Seek 范围优化器转向扫描。-- OR 条件落在同一索引列上的典型场景优化器可拆成 Seek SELECT SalesOrderID FROM Sales.SalesOrderHeader WHERE Status 3 OR Status 5; -- OR 一边能 Seek一边套函数整体退化 SELECT SalesOrderID FROM Sales.SalesOrderHeader WHERE SalesPersonID 285 OR YEAR(OrderDate) 2024;第一段两个等值条件在同一列上优化器可以把它处理成多个 Seek 谓词。第二段右边是非 SARGable整个谓词无法准确映射到索引键范围即便 SalesPersonID 上有索引优化器也可能放弃它。实际计划里也可能出现“SalesPersonID Seek 回表再过滤右边”的折中方案具体看选择性重点是排查时先看最弱的那个 OR 分支它决定了整个谓词能不能被索引接住。参数说明遇到这种结构常见做法是把 OR 分支拆成两条查询用 UNION ALL 合并让每条查询独立走索引。不要用 UNION去重排序的开销在这种场景里是白付的。如果 OR 分支来自同一列的不同值优先改写成 IN 列表计划更简洁也方便基数估算。4. 数据与环境的退化统计信息失真、参数嗅探与基数估算翻车写法没问题索引也没错那问题就出在优化器拿到的“情报”上统计信息不准、缓存计划被污染、基数估算模型判断失误。这一层最像玄学但每一条都能用脚本验证。4.1 统计信息蒙住优化器的眼睛估算行数决定计划的底座优化器在决定走 Seek 还是 Scan 之前先要回答“这个谓词预计返回多少行”。这个答案来自统计信息的直方图SQL Server 把索引列的值域按步长切分记录每段的行数。直方图最多保留约 200 个步长遇到数据分布极不均匀的列尖峰很容易被合并进某一段估算行数会和实际差出数量级。还有采样率问题。自动更新统计信息默认按抽样比例采样大表抽样率低时直方图与真实分布偏差更大。另外自动更新有触发阈值旧版本是“变更行数超过表行数的 20% 左右”才触发SQL Server 2016 之后对不同大小的表用了动态阈值但对超大表仍然存在滞后窗口。批量灌数据之后没达到阈值、或者索引刚重建完没来得及更新都是典型的退化窗口。-- 查看统计信息的具体分布 DBCC SHOW_STATISTICS(Sales.SalesOrderHeader, IX_SalesOrderHeader_OrderDate); -- 手动刷新数据倾斜列建议 FULLSCAN UPDATE STATISTICS Sales.SalesOrderHeader IX_SalesOrderHeader_OrderDate WITH FULLSCAN;第一句返回三个结果集统计信息头、密度、直方图。重点看直方图里的 RANGE_HI_KEY、EQ_ROWS、AVG_RANGE_ROWS如果某段区间实际新增了大量数据直方图里没有对应的尖峰说明统计过期了。第二句用 FULLSCAN 全表重建直方图分布最真实代价也高适合放在维护窗口对问题索引单独执行。参数说明sp_updatestats 会把库内所有表的统计信息刷一遍动作粗且耗时不建议当成首选。先定位到具体索引查看直方图确认失真程度再决定是否用 FULLSCAN。对大表可以先按默认采样刷新一次看估算有没有回正回正就不必 FULLSCAN 了。4.2 参数嗅探一个倒霉的第一次让所有精查询共用扫描计划参数化查询第一次编译时优化器会把传入的参数实际值代入统计信息做估算。这个第一次如果碰上匹配大量行的“脏参数”生成的计划就是 Scan。这计划被缓存下来之后所有参数值执行时都复用这份 Scan 计划哪怕某个参数值只匹配个位数行索引查找也永远不再出现。识别参数嗅探有一个很朴素的方法同一个存储过程或批处理在图形计划里看是 Scan单独加一句 OPTION (RECOMPILE) 重跑计划变成 Seek而且耗时明显下降。这种“同一个写法、换个执行环境计划就变了”的差异基本就是缓存计划在作祟。-- 1) 定位目标语句的 plan_handle SELECT qs.plan_handle, st.text, qs.execution_count, qs.last_execution_time FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st WHERE st.text LIKE %SalesOrderHeader% AND st.text LIKE %CustomerID %; -- 2) 清除该语句的缓存计划让它重新编译 DBCC FREEPROCCACHE(0x06000600...); -- 3) 语句级重新编译避免复用旧计划 SELECT SalesOrderID, OrderDate FROM Sales.SalesOrderHeader WHERE CustomerID CustomerID OPTION (RECOMPILE);第一步在 dm_exec_query_stats 里找到目标语句的 plan_handle第二步只清掉这条计划不影响其他缓存。第三步的 RECOMPILE 让这条语句每次执行都重新编译按当前参数实际值估计划代价是每次多花一点编译时间。参数说明OPTION(RECOMPILE) 适合执行频率低、参数漂移严重的语句。一秒执行几十次的语句不建议加编译开销会放大。中低频场景用 RECOMPILE 常用常新SQL Server 2022 的 Parameter Sensitive Plan Optimization 会自动为不同参数值区间缓存多份执行计划减少手动干预升级到 2022 后这类场景可以少写提示。4.3 基数估算翻车多谓词相关性让选择性被算错SQL Server 2014 开始默认使用新的基数估算CE模型。新模型对多重谓词的处理和旧模型不一样常见的问题是低估或高估叠加过滤后的行数。比如查询里同时过滤 CustomerID 和 OrderRegion这两个列如果业务上本来就强相关新 CE 按独立性假设把两个选择性相乘估算结果远低于实际行数优化器可能生成 Seek 大量回表也可能反过来因为高估而选 Scan。这种问题在计划里的特征很明确Estimated Rows 和 Actual Rows 相差数十倍而且同一条语句换个参数值计划在 Seek 和 Scan 之间横跳。排查时可以先把谓词拆开逐个条件单独执行看估算是否准确再用多列统计信息补相关性。多列统计信息能缓解但管不了所有场景。-- 这条语句强制使用旧版基数估算做 A/B 对比 SELECT SalesOrderID, OrderDate FROM Sales.SalesOrderHeader WHERE CustomerID CustomerID AND OrderRegion OrderRegion OPTION (USE HINT(FORCE_LEGACY_CARDINALITY_ESTIMATION));USE HINT(FORCE_LEGACY_CARDINALITY_ESTIMATION) 让当前语句回到 2014 前的 CE 模型适合判断“新 CE 对这条查询的估算是否翻车”。如果换旧 CE 后计划变回 Seek 且 Actual Rows 恢复正常说明是 CE 模型对数据相关性的判断问题而不是索引和写法的问题。参数说明这种开关只用于对照验证不解决根本。根本手段还是让优化器拿到准确的统计信息、让谓词 SARGable、让选择性真实的索引存在。Trace Flag 9481 和 4199 也能全局切换 CE 或启用修复项但影响面大不到万不得已不建议在生产库全局开先在干净会话里验证。5. 避坑清单索引查找退化里踩过的 5 个坑与排查顺序下面这 5 个场景都是实际维护中容易被误导的案例按“现象 → 原因 → 解决”的顺序写遇到类似情况可以对照着排查。5.1 统计信息刷新了计划还是扫描现象线上查询从 Seek 变 Scan按常规先执行了 sp_updatestats再看计划依旧扫描。原因sp_updatestats 是大规模刷新对超大表可能采用较低采样率直方图没有捕捉到关键的倾斜数据分布甚至可能因为时间窗口或跳过条件出问题的那个索引统计没被更新。另一个可能是统计更新了但直方图步长合并后依然刻画不了尖峰。解决针对具体索引执行 UPDATE STATISTICS ... WITH FULLSCAN然后重新查看 DBCC SHOW_STATISTICS确认直方图里对应键值的 EQ_ROWS 发生了明显变化。如果 FULLSCAN 后还是 Scan再看 XML 执行计划里的 StatisticsInfo 节点确认引用的统计信息是不是刚刷的那一份避免计划缓存里还是旧版本的估算。5.2 加了 INCLUDE 列之后Scan 变 Seek 但查询更慢了现象给索引补上 SELECT 需要的 INCLUDE 列后执行计划从 Index Scan 变成了 Index Seek但查询耗时变大SET STATISTICS IO 里 logical reads 比之前还高。原因Scan 有预读和顺序 IO 兜底Seek 是按键值逐条随机读。当 Seek 返回的行数分散在大量数据页上时即使占比不高随机 IO 的开销也会超过一次完整顺序扫描。执行计划看起来“健康”了物理代价反而更大。解决不要只看操作符要看 logical reads 和执行总耗时。遇到这种情况优先调整索引键顺序让 Seek 谓词对应的是索引最前导列缩小 Seek 返回行数如果查询条件自身选择性就不足 5% 到 10%Scan 可能本来就是正确答案别硬扭。5.3 FORCESEEK 验证时很香上线更慢现象怀疑优化器算错账加了 WITH (FORCESEEK) 强制走 Seek测试环境执行很快发布到生产后响应时间更差。原因FORCESEEK 直接绕过了成本比较强制生成 Seek 计划。匹配行数越多后续回表的次数越多随机 IO 被放大。测试环境数据量小这条增长曲线还没起来看不出问题。解决FORCESEEK 当诊断工具用不当修复手段。看到 Seek 计划能跑通、能确认问题不在写法之后马上去掉提示回到索引层面解决。给索引补 INCLUDE、调整前导列、改写谓词让 Seek 本身变便宜才是正路。5.4 JOIN 键两边都是 INT计划里却出现了 CONVERT_IMPLICIT现象两个表关联字段定义都是 INT执行计划里却看到 CONVERT_IMPLICIT 转换关联列上的索引没有用上。原因一边是 INT另一边可能是 SMALLINT 或 TINYINT。INT 优先级高低优先级的列会被提升成 INT如果被提升的列恰好在索引键上索引就被包了一层转换Seek 失效。两边都叫 XXID看着像同类型实际长度和类型族不同是最常见的翻车点。解决先用 sys.columns 查询两边的精确类型。应用层不好改时给非索引侧做显式 CAST保住索引侧不被转换。比如 WHERE 大表.索引列 CAST(小表.关联列 AS INT)把转换挪到小表一方索引列保持原样。5.5 IS NULL 谓词让优化器“没法估”现象查询里有 WHERE DeletedFlag IS NULL这个条件选择性其实很好却总是走扫描给列建了普通索引也没改善。原因统计信息的直方图里没有 NULL 对应的条目优化器对 NULL 的选择性几乎没有参考数据只能按默认猜测处理Seek 的收益算不出来自然选了更保守的 Scan。解决业务上给 NULL 一个明确的默认语义比如删除状态列一律填 0 表示未删除查询改成 WHERE DeletedFlag 0普通索引就能接住。另一种做法是建过滤索引CREATE INDEX IX_SalesOrderHeader_DeletedFlag ON Sales.SalesOrderHeader (DeletedFlag) WHERE DeletedFlag IS NULL; 过滤索引自带独立的统计信息IS NULL 这条路就有据可依了。注意过滤索引要覆盖查询里用到的其他列避免回表太多。6. 最后一里路用 A/B 验证给结论上保险排查到这一步手上通常有候选方案改写谓词、更新统计信息、调索引键顺序、补 INCLUDE。但任何改动上线前都要先做一次可对比的验证。我的标准动作是先记录基线再改动再对比最后才决定上不上线。-- 基线原始查询 SET STATISTICS IO, TIME ON; SELECT SalesOrderID, OrderDate, TotalDue FROM Sales.SalesOrderHeader WHERE YEAR(OrderDate) 2024; SET STATISTICS IO, TIME OFF; GO -- 改动后改写谓词同时标记计划 SET STATISTICS IO, TIME ON; SELECT SalesOrderID, OrderDate, TotalDue FROM Sales.SalesOrderHeader WHERE OrderDate 2024-01-01T00:00:00 AND OrderDate 2025-01-01T00:00:00; SET STATISTICS IO, TIME OFF; GO对比时先看 logical reads再看耗时。逻辑读是页访问次数不受缓存影响耗时受机器负载影响只作辅助。两段查询之间不要清缓存清缓存会引入预读波动干扰对比。如果两张计划一个 Seek 一个 Scan但 logical reads 接近那改写收益不大只有 logical reads 明显下降才算真正优化成功。有条件的话在测试实例上把两条 Select 放进同一批处理里各跑三次取中位数能避开抖动。我自己早期调索引只看执行计划从 Scan 变成 Seek 就在记录里写“优化完成”后来对比 logical reads 才发现从 200 涨到 900脸被打肿。之后所有改动都先留基线再谈上线。写 SQL 调优操作符只是表象IO 数字才是体检报告。希望帮到你。本文还有配套的精品资源点击获取
