SQL Server：为何基于索引过滤时仍读取所有行？

API 探路者

2026-5-25

为什么带ID索引的小表查询仍有大量读取？

嘿，这个问题挺耐人寻味的——才200行的Users表，ID列明明建了索引，半数查询却跑出112次读取、16ms耗时，确实有点反常。结合SQL Server的常见排查思路，我给你列几个最可能的原因，以及对应的排查方向：

1. 查询优化器没用到你的ID索引，走了全表扫描

虽然你建了ID索引，但SQL Server的查询优化器是“成本驱动”的——如果它觉得全表扫描的成本比用索引更低，就会放弃索引。这种情况常见于：

统计信息过时：优化器依赖统计信息判断表的行数和数据分布，如果统计信息很久没更新，它可能误以为Users表有几万行，反而觉得全表扫描更划算。你可以手动更新统计信息试试：
```
UPDATE STATISTICS Users;
```
查询写法导致索引失效：比如对ID列做了隐式转换或函数操作，比如WHERE CAST(ID AS VARCHAR(10)) = '123'，或者WHERE ID + 1 = 124，这会让索引直接失效，优化器只能走全表扫描。检查下你的查询语句有没有这类操作。

如果你的查询需要返回ID之外的其他列（比如SELECT * FROM Users WHERE ID = @UserId），而ID索引只是单列索引，那么优化器会先通过索引找到对应的ID行，再回表去读取其他列的数据——这就是键查找。200行的表如果有大量键查找，累加起来的读取量就会很高。

解决方法是改成覆盖索引，把查询需要的所有列都包含进去，比如：

CREATE NONCLUSTERED INDEX IX_Users_ID_Covering ON Users(ID)
INCLUDE (UserName, Email, CreateDate); -- 替换成你查询需要的列

这样查询直接从索引里就能拿到所有数据，不用回表，读取量会立刻降下来。

虽然200行的表碎片影响不大，但如果Users表频繁有插入、删除操作，索引可能产生碎片，导致读取效率下降。你可以查看索引碎片情况：

SELECT * FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('Users'), NULL, NULL, 'DETAILED');

如果碎片率超过30%，可以重建索引：

ALTER INDEX IX_Users_ID ON Users REBUILD;

如果你的查询是带参数的（比如存储过程里的WHERE ID = @UserId），第一次执行时的参数值可能让优化器生成了一个不适合后续参数的执行计划。比如第一次查的是一个不存在的ID，优化器选了全表扫描，之后即使查存在的ID，也复用了这个计划。

你可以试试在查询末尾加OPTION (RECOMPILE)，强制优化器重新生成执行计划，看看读取量是否下降：

SELECT * FROM Users WHERE ID = @UserId OPTION (RECOMPILE);

不管上面哪种情况，先看实际执行计划是最快定位问题的方法。在SSMS里执行查询时，点击“包括实际执行计划”按钮（快捷键Ctrl+M），执行后就能看到优化器到底用了什么操作：

内容的提问来源于stack exchange，提问作者danielson317