嵌套子查询本身不直接触发Bookmark Lookup，但当迫使优化器选择非覆盖索引+聚集索引查找时，因SELECT列未被索引覆盖而引发Key Lookup；避免关键在于构建覆盖索引（含INCLUDE列）并裁剪投影。

为什么嵌套子查询会触发Bookmark Lookup

嵌套子查询本身不直接导致Bookmark Lookup，但当它迫使优化器选择非覆盖索引 + 聚集索引查找组合时，问题就出现了。典型场景是：WHERE里用子查询过滤，而SELECT里又要求返回未被索引覆盖的列（比如SELECT name, email FROM users WHERE id IN (SELECT user_id FROM logs)），SQL Server先用logs.user_id索引快速定位主表users.id，再回表取name和email——这就是Key Lookup（旧称Bookmark Lookup）。

OUTER APPLY替代标量子查询能绕过Lookup吗

不能自动绕过，但给了你控制索引路径的机会。关键不在语法切换，而在右表索引是否覆盖所需字段。

• 错误做法：只在orders.user_id建单列索引，OUTER APPLY仍需回表取order_date
• 正确做法：建复合索引CREATE INDEX IX_orders_user_date ON orders(user_id, order_date DESC)，这样TOP 1 ... ORDER BY order_date DESC就能完全走索引查找，零回表
• 如果还要返回amount、status等字段，必须把这些也加进索引的INCLUDE部分，否则依然触发Key Lookup

IN子查询改JOIN后如何避免Lookup

IN子查询改写为INNER JOIN是常见优化手段，但若JOIN后仍要查非索引列，Lookup照旧。真正起作用的是索引设计+投影裁剪。

• 先确认JOIN条件字段已有索引（如logs.user_id → users.id，则logs.user_id需有索引）
• 把SELECT中所有来自右表（logs）的字段，全部纳入右表索引的INCLUDE列表，例如：CREATE INDEX IX_logs_user_id_incl ON logs(user_id) INCLUDE (log_time, action, ip)
• 避免SELECT *，只取业务真正需要的列——少一列，就少一次可能的Lookup

窗口函数嵌套方案对Lookup的影响

用ROW_NUMBER()嵌套去重（如找每个用户的最新订单）本身不引入Lookup，但外层查询若引用了未覆盖的列，Lookup仍会发生。

• 内层CTE或子查询只负责生成rn = 1标记，不涉及实际数据读取
• Lookup发生在最终SELECT *阶段，所以必须确保最终FROM的表（或视图）所依赖的索引已覆盖全部SELECT列
• 最稳妥做法：把窗口计算和主表查询合并到同一张覆盖索引上，例如在orders表上建(user_id, order_date DESC) INCLUDE (order_id, amount, status)

真正卡住性能的从来不是“用了子查询”，而是“没让索引覆盖查询路径上的所有列”。无论你选APPLY、JOIN还是CTE，只要执行计划里还出现Key Lookup图标，说明索引还没配齐。