WHERE多OR条件查询最优索引策略及慢更新SQL语句优化咨询

针对你遇到的两个数据库性能问题，我结合实战经验给你梳理下可行的优化方案：

当WHERE子句包含多个OR条件时，数据库优化器往往很难高效利用单一索引，这里分享几个实用策略：

• 优先用IN替代同字段的OR：如果OR条件是针对同一个字段的（比如WHERE id = 1 OR id = 2 OR id = 3），直接换成WHERE id IN (1,2,3)，普通的单列索引就能完美适配，执行效率会高很多。
• 创建覆盖索引：如果OR条件涉及不同字段（比如WHERE a = 'x' OR b = 'y'），可以创建包含所有OR条件字段+查询返回字段的覆盖索引。比如你的查询是SELECT col1, col2 FROM table WHERE a='x' OR b='y'，就建索引CREATE INDEX IX_table_a_b_cols ON table(a, b) INCLUDE (col1, col2);，这样数据库不用回表就能拿到所有需要的数据，避免额外的IO开销。
• 拆分语句用UNION ALL合并结果：如果OR条件的字段无法通过单一索引优化，可以把语句拆成多个单条件查询，再用UNION ALL合并。比如把SELECT * FROM table WHERE a='x' OR b='y'拆成：

  SELECT * FROM table WHERE a='x'
  UNION ALL
  SELECT * FROM table WHERE b='y' AND a!='x' -- 加a!='x'避免重复数据
  

  然后给a和b分别建单列索引，这样每个子查询都能用到索引，整体效率会比原语句高。
• 利用数据库的索引合并特性：部分数据库（比如MySQL、SQL Server）支持索引合并，会自动为OR条件的多个字段分别使用对应的单列索引，再合并结果。但这个特性依赖数据库优化器的判断，你可以通过执行计划验证是否生效，如果没生效再考虑上面的手动优化方案。

从你描述的场景来看，1200行的临时表关联20万行的Products表却出现高读取次数，核心问题肯定是关联条件缺少合适的索引，或者索引没有覆盖所需字段。具体优化步骤如下：

• 给临时表的关联字段建索引：假设你的UPDATE语句关联条件是tmp.product_id = pd.product_id，那一定要给临时表#temptable的product_id字段建索引。因为临时表数据量小（1200行），建聚集索引效率最高：

  CREATE CLUSTERED INDEX IX_temptable_product_id ON #temptable(product_id);
  

  如果临时表还有其他过滤条件，也可以把过滤字段加入索引的前缀。
• 给Products表建覆盖索引：Products表的关联字段（比如product_id）如果不是主键，要给它建非聚集索引，并且包含UPDATE需要读取的col1、col2、col3，这样数据库不用回表查找这些字段，直接从索引里拿数据：

  CREATE NONCLUSTERED INDEX IX_Products_product_id_cols ON Products(product_id) INCLUDE (col1, col2, col3);
  

  如果product_id已经是主键（自带聚集索引），那只需要确保col1、col2、col3在索引的包含列里，或者如果主键索引已经覆盖这些字段就不用额外建了。
• 更新临时表的统计信息：临时表的统计信息有时候会不准确，导致优化器选择糟糕的执行计划，可以手动更新统计信息：

  UPDATE STATISTICS #temptable;
  

• 优化关联语句的写法：把旧的逗号分隔关联改成INNER JOIN的显式写法，不仅可读性更好，也有助于优化器更清晰地识别关联逻辑：

  UPDATE tmp 
  SET tmp.col1 = pd.col1, tmp.col2 = pd.col2, tmp.col3 = pd.col3 
  FROM #temptable tmp 
  INNER JOIN Products pd ON tmp.product_id = pd.product_id; -- 这里替换成你的实际关联条件
  

这些优化做完后，你可以再用Profiler或者执行计划工具验证读取次数和执行时间，应该会有明显的提升。

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