关于SQL Server2005中的Bookmark Lookup一点疑惑!!!

2010-08-26 08:51:43 63 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

SQL Server键查找（Key Lookup）性能问题与覆盖索引优化键查找（Key Lookup）是SQL Server中非聚集索引无法覆盖查询列时触发的二次寻址操作，本质是因索引缺失关键字段导致的额外I/O开销。其原理源于B+树索引结构限制：非聚集索引叶子节点仅存储键值与行定位符（RID或聚集键），当SELECT或WHERE涉及未包含列时，引擎必须回表获取完整数据行。该操作显著推高逻辑读、CPU及端到端延迟，尤其在百万级数据和高并发场景下易引发性能雪崩。技术价值在于揭示索引设计的核心矛盾——覆盖性与维护成本的平衡；典型应用场景包括用户查询、订单详情、报表接口等需高频点查+ 阅读详情



--创建表

if OBJECT_ID('news') is not null

	drop table news

create table news

(

	news_id bigint primary key,

	news_content varchar(8000),

	news_datetime datetime

)



--为时间列建立索引

create index idx_datettime on news(news_datetime)

如上代码所示，创建一个新闻表news，其中有3列分别是ID，新闻内容，添加时间；其中news_id为默认的聚集索引，手动为“添加时间”列加上了非聚集索引；
我在书上看到非聚集索引只能返回索引关键列，也就是说我只查询时间列是高效的，如下：



select news_datetime from news 

	where news_datetime between '2010-08-18 16:03' and '2010-08-18 16:04'

如果我一次性查询所有的列用select *，SQL Server的执行计划会直接用聚集索引扫描所有的行，这个时候news_datetime的索引是不是就没什么效果了，下面是执行计划的IO情况：



select * from news 

	where news_datetime between '2010-08-18 16:03' and '2010-08-18 16:04'

表'news'。扫描计数1，逻辑读取23045 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，

因为非聚集所以默认情况下，都包含本表的聚集索引列，也就是说我用news_datetime作谓词查找，只查询news_id 是索引查找，而不是扫描，然后我突发奇想写下这样的SQL：



select * from news where news_id in(

	select news_id from news

		where news_datetime between '2010-08-18 16:03' and '2010-08-18 16:04')

表面上看多了个嵌套，但我惊奇的发现尽管这条SQL长，看似复杂，但是IO情况却比上面要好,如下：
表'news'。扫描计数2，逻辑读取19016 次，物理读取0 次，预读0 次，lob 逻辑读取0 次，lob 物理读取0 次，

最后我看执行时间的确下面比上面的好快不少。虽然效率差别不大，但是心中有疑惑，还忘各位SQL大人帮忙看下；区别到底在哪里，他们内在的执行的机制和顺序有何不同！

...全文