select count(*) from tb是否需要扫描全部的索引中间层？

[nzperfect]

表tb有聚集索引,有13个索引中间页.
那么在select count(*) from tb时，发现全走全部的索引中间层叶.

从理论上讲，由于每个数据页都记录着它的上一个page和下一个page,那么最小的io读取应该是:
读根页--->读最小的中间页--->读数据叶子---->依次往后读全部数据页.

但实际上却是读取全部的索引中间页，谁能解释一下？

附部分代码：

use tempdb
go
CREATE TABLE tmp (id int  ,c1 char(500),c2 char(500))
CREATE CLUSTERED INDEX CI_id ON tmp(id)
DECLARE @i INT
SET @i=0
WHILE @i<20129
BEGIN
    INSERT INTO tmp(id,c1,c2)
    SELECT @i,'a','z'
    SET @i=@i+1
END

set statistics io on
select COUNT(*) from tmp

DBCC IND(tempdb,tmp,-1)

dbcc traceon(3604)
dbcc page(tempdb,1,1666,3)
dbcc page(tempdb,1,196,3)
dbcc page(tempdb,1,193,3)

[风云1978]

学习一下,大家都发表一下自己的意见

[黄_瓜]

引用 119 楼 xman_78tom 的回复:

预读应该是普遍机制，数据库引擎在执行查询前是不会预先知道所要查询的数据是否都被缓存，因此在执行 index scan 时都必须读取中间级索引页，以辅助预读。

猫兄的回答总是那么精辟，越来越崇拜你了

[wjlsmail]

是不是聚集函数都会引发类似的扫描？

[nzperfect]

我今天在想一个问题可以推翻之前的想法，并且可以解释count(*)的问题：

sql server 在读取索引数据层数据时，有可能是通过索引中间层读出符合条件的全部数据层的数据页pageid列表，然后通过这个列表去读数据页。而不是通过索引中间层找到其中一个数据页，通过该数据页中标记的nextpageid来读取下一个数据页。

预读机制并不是count(*)扫描全部索引层的最好解释，因为预读时，即使你只取一条数据，预读也可能是读全部的索引中间层及中部分数据页，因为sql server 总是尽可能的缓存数据表的数据以送减小io.这个可以通过

DBCC DROPCLEANBUFFERS --无法清除tempdb的缓存数据.(所以不要使用tempdb库做测试)
SELECT bd.*
FROM sys.dm_os_buffer_descriptors AS bd
    INNER JOIN
    (
        SELECT object_name(object_id) AS name
            ,index_id ,allocation_unit_id
        FROM sys.allocation_units AS au
            INNER JOIN sys.partitions AS p
                ON au.container_id = p.hobt_id
                    AND (au.type = 1 OR au.type = 3)
        UNION ALL
        SELECT object_name(object_id) AS name 
            ,index_id, allocation_unit_id
        FROM sys.allocation_units AS au
            INNER JOIN sys.partitions AS p
                ON au.container_id = p.partition_id
                    AND au.type = 2
    ) AS obj
        ON bd.allocation_unit_id = obj.allocation_unit_id
WHERE database_id = db_id() and name='tbname'
ORDER BY allocation_unit_id,page_type

通过执行此查询语句，可以发现执行select count(*) from tbname时，缓存全部的索引中间层和数据层，并未缓冲IAM页，所以不知count(*)时是否读取IAM页？另外，如查执行select * from tbname where id=1，可以发现预读机制可能会缓存全部索引中间层及差不多一半的数据层，但逻辑读只有3个page.

[Leshami]

学习

回复内容太短了！

[Sybase数据库恢复]

引用 153 楼 perfectaction 的回复:

我今天在想一个问题可以推翻之前的想法，并且可以解释count(*)的问题：

sql server 在读取索引数据层数据时，有可能是通过索引中间层读出符合条件的全部数据层的数据页pageid列表，然后通过这个列表去读数据页。而不是通过索引中间层找到其中一个数据页，通过该数据页中标记的nextpageid来读取下一个数据页。

预读机制并不是count(*)扫描全部索引层的最好解释，因为预读时，即使你只取一条数据，预读也可能是读全部的索引中间层及中部分数据页，因为sql server 总是尽可能的缓存数据表的数据以送减小io.这个可以通过
SQL codeDBCC DROPCLEANBUFFERS--无法清除tempdb的缓存数据.(所以不要使用tempdb库做测试)SELECT bd.*FROM sys.dm_os_buffer_descriptorsAS bdINNERJOIN
(SELECTobject_name(object_id)AS name
,index_id ,allocation_unit_idFROM sys.allocation_unitsAS auINNERJOIN sys.partitionsAS pON au.container_id= p.hobt_idAND (au.type=1OR au.type=3)UNIONALLSELECTobject_name(object_id)AS name
,index_id, allocation_unit_idFROM sys.allocation_unitsAS auINNERJOIN sys.partitionsAS pON au.container_id= p.partition_idAND au.type=2
)AS objON bd.allocation_unit_id= obj.allocation_unit_idWHERE database_id=db_id()and name='tbname'ORDERBY allocation_unit_id,page_type

通过执行此查询语句，可以发现执行select count(*) from tbname时，缓存全部的索引中间层和数据层，并未缓冲IAM页，所以不知count(*)时是否读取IAM页？另外，如查执行select * from tbname where id=1，可以发现预读机制可能会缓存全部索引中间层及差不多一半的数据层，但逻辑读只有3个page.

假设索引有3层。中间层和叶子层上的索引时分别单独自己串联起来的。中间层指向其所索引的第一个叶子层页面。
为了得到数据页面的页号信息，中间层的页面应该是最便捷的（长远来说，虽然目前你这个例子不是最好）。

另外，预读了不一定本次用。其他会话可能遇到高速缓存的预读数据。

对于sybase，我已经分析出来了索引的物理存储结构。请查看：http://blog.csdn.net/andkylee/archive/2010/03/01/5337013.aspx

[jwwyqs]

学习
！！！！！！

[adnin2010]

学习.

[nzperfect]

谢谢大家的讨论，暂时结了。

[wenboliang]

看不懂是什么东西 东方饭店的的的的

[baisiye]

很强大~~~~~~~~~~~~

[蛙易]

学习了（它说我回复的内容太短了）

[lcw321321]

mark,回复内容太短了

[live360]

[时光审美]

越来越深入了 顶起学习。。。数据啊数据。

[liuhaifeng1976]

dingdingdingding

[javazhou1988]

来看看..............

[keyyi]

高贴，mARK一下


回复内容 回复内容太短了！

[zhangqiang0538]

想想想想想想想想想想不出来

[lawbc]

太深奥了，俺不懂啊 ，呵呵