嵌套子查询本身不直接触发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图标，说明索引还没配齐。 
