聚集索引在IN/OR子句中失效？求强制Index Seek方法及原因解析

这个问题我碰到过好多次，其实是数据库优化器的成本估算逻辑在起作用，我来给你掰扯清楚：

数据库优化器的核心目标是选择成本最低的执行路径，它会对比不同执行方式的IO、CPU开销，然后做决策：

• 当你用单值查询WHERE user_id = 1时，聚集索引的Index Seek可以直接定位到该键值对应的叶子节点，直接取出数据，开销极小，优化器肯定选它。
• 当改用OR或IN包含多个值时，优化器会评估两种路径的成本：
  1. 对每个值单独做一次Index Seek，然后合并结果；
  2. 直接扫描整个聚集索引（也就是整个表）。
• 如果你的表数据量很小（比如只有几百行），扫描整个表的IO开销其实比多次Seek加起来还低，优化器自然会选Scan；
• 要是统计信息过时，优化器没办法准确判断匹配行数的占比，也可能错误地选择Scan；
• 另外，如果匹配的行数占表的比例较高（比如超过10%-20%），优化器会认为扫描比多次Seek更高效，因为合并结果的CPU开销会更高。

如果你确定Index Seek更适合你的场景，可以试试这几种方法：

• 用UNION ALL拆分查询：把多值查询拆成多个单值查询，每个子查询都会触发Index Seek，最后合并结果。这种方法最稳妥，不会有强制提示的副作用：

  SELECT * FROM user WHERE user_id = 1
  UNION ALL
  SELECT * FROM user WHERE user_id = 2;
  

• 使用查询提示（谨慎使用）：比如在SQL Server里可以用FORCESEEK强制优化器选择索引查找。但要注意，这会跳过优化器的成本估算，如果匹配行数很多，反而会降低性能，所以只在你确定Seek更优时用：

  SELECT * FROM user WITH (FORCESEEK) WHERE user_id IN (1,2);
  

• 更新统计信息：如果是统计信息过时导致优化器判断错误，更新统计信息后它可能会自动选择Index Seek：

  UPDATE STATISTICS user;
  

最后提一句：优化器的选择大部分时候是合理的，如果你的表很小，Scan的性能并不会比Seek差太多，没必要强行修改。只有当表数据量很大，且匹配行数很少时，强制Seek才有实际意义。

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