相关子查询性能差主因是索引未覆盖子查询中WHERE和SELECT涉及的所有列，需用INCLUDE确保order_date等过滤列被索引“看见”，否则引发大量Key Lookup导致IO激增。
相关子查询性能差，八成不是写法问题，而是索引没覆盖 SELECT 和 WHERE 里用到的所有列。
为什么相关子查询特别吃索引
相关子查询每次外层行迭代都要执行一次内层查询，比如 WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id AND o.order_date > ...) —— 如果 orders 表上只有 customer_id 单列索引，SQL Server 就得先定位到所有匹配的 customer_id 行，再逐行回表查 order_date 值做判断，产生大量 Key Lookup 操作。
这种来回跳转在几百万行数据下开销极大，IO 成倍上升。
- 执行计划里出现红色警告图标或高占比的
Key Lookup，就是典型信号 -
STATISTICS IO ON显示逻辑读远高于预期（比如上千次），说明频繁回表 - 子查询中
WHERE条件列和SELECT列（哪怕只是SELECT 1）都必须被索引“看见”
覆盖索引怎么建才对：INCLUDE 不是可选项，是刚需
对相关子查询，非聚集索引必须把子查询里所有涉及的列都“收进来”，否则优化器宁愿走全表扫描也不用半吊子索引。
以订单子查询为例：
EXISTS (
SELECT 1
FROM orders o
WHERE o.customer_id = c.customer_id
AND o.order_date > DATEADD(month, -3, GETDATE())
)
正确索引是：
CREATE NONCLUSTERED INDEX IX_orders_customer_date ON orders (customer_id) INCLUDE (order_date);
-
customer_id放在键列（用于快速定位），order_date必须进INCLUDE—— 否则索引无法过滤order_date条件 - 如果子查询里还有
status或amount等字段参与判断，它们也得加进INCLUDE - 不要试图把
order_date加进键列搞复合索引（如(customer_id, order_date)），除非你同时有按时间范围排序或分组的需求；否则会扩大索引体积，降低缓存效率
容易踩的坑：覆盖了子查询，但漏了外层字段
覆盖索引只解决子查询部分。如果外层查询本身也返回大量列，比如 SELECT c.*, c.name, c.email, c.phone FROM customers c WHERE EXISTS (...)，而 customers 表没有合适索引，主表扫描照样拖慢整体速度。
- 确认外层表的连接/过滤字段是否有索引（如
customers.id被orders.customer_id引用，那customers.id应该是聚集索引或有唯一索引） - 如果外层
SELECT返回宽表字段，考虑是否真需要全部——能投影精简就精简，避免无谓的 LOB 读取 - 别迷信
SELECT *：它会让覆盖索引失效于外层，因为优化器无法保证索引能提供所有列
真正卡住性能的，往往不是子查询多嵌套了几层，而是每一层都缺一个刚好够用的 INCLUDE 列。建之前先看执行计划里哪些操作亮红灯，再对着字段一个个补，比盲目堆索引管用得多。
