SQL SERVER 如何读取页面上的数据
CSDN上有篇帖子http://topic.csdn.net/u/20100223/15/644e6212-9fdc-42de-81ad-785d28ed71d3.html
讨论查询计划读取索引页的问题。
主要问题是： 在一张建有聚集索引（没有其它非聚集索引）的表执行select count(*) 。查询显示扫描了所有的索引中间层叶。从理论上讲，由于每个数据页都记录着它的上一个page和下一个page,那么最小的io读取应该是:
读根页--->读最小的中间页--->读数据叶子---->依次往后读全部数据页.
但实际上却是读取全部的索引中间页。
帖子中比较精彩的回复：
首先楼主的说法不够准确，根据我的测试结果来看，更准确的说法应该是sql server在做索引全扫(index full scan)时，会先扫描全部的level 1的节点，然后在扫描处于level 0的叶节点。也就是说一次索引全扫的顺序是（这个顺序对于clustered index和普通index都是一样的）：
读根页--->读最小的中间页（level 1以上的层）--->依次读level 1的所有节点的索引页---->读全部数据页
上述顺序可以在将数据表索引层数增加到3层以上时得到验证。
实际上我觉得sql server这样做是很有道理的，楼主认为的是所读的页越少，io就越小，这是不对的。对于sql server来说，一次io并不一定只读取一个页，很多时候特别是做表全扫或索引全扫时，sql server都会尽量的让一次io读取尽可能多的数据页，这样才能较少io的次数。为达到这个目的，sql server首先就要知道它到底需要读取那些页，知道要读取页的分布之后，就可以安排io调度器尽可能的将临近的数据页用一次io读取上来，而要知道需要读取数据页的分布就需要先读取到level 1上的所有页，以找出要读取io页的分布情况，然后再做最优的io读取安排。
同样的道理，如果sql server是先定位到叶节点的起始数据页，然后从依次的读取所有的数据页的话，那sql server就只能一次io读取一个数据页，然后找出对应的下一页的指针，再去读取下一个数据页，这样实际上花费的io会远比批量读取数据页多很多的。这就好比我们在做表的lookup时，如果需要lookup的行非常之多的话sql server会转而选择表扫描来达到目的的。
预读
我觉得SQL Server内部存在这样一个机制:
它会尽量将当前使用的及使用最频繁的表的数据都带到buffer中来，这跟buffer的算法有一定的关系。
清掉buffer後，你不做任何动作，隔几秒钟，sql会自动将master库中一些比较重要的表都带到buffer中，或者
你select * from tb where 1 <>1 ，尽�
相关文档：
郑重声明一下，这篇日志是我Copy的，不是自己写的，我还没那么强！(仔细看一下，有用。)
关于SQL语句中的双引号、单引号：
（1）先来看一个最简单的SQL语句
Insert Into users(username) values("小王")
大家来� ......
例子：
if 1<>1
begin
if 5<0
begin
print('失败')
end
else begin
&nbs ......
SQL Server
从数据库表中的第M条记录开始取N条记录，利用Top关键字：注意如果Select语句中既有top，又有order by，则是从排序好的结果集中选择：
SELECT *
from ( SELECT Top N *
from (SELECT Top (M + N - 1) * from& ......
1. In "MicroSoft SQL Server Management Studio", right click SQL Server instance, select "Properties", select "Security" in left panel and check "SQL Server and Windows Authentication mode" in right Panel.
2. In "SQL Server Configuration Manager", select "SQL Server Network Configuration > ......
通过第七期和第八期的文章，我们了解了SQL SERVER 2005数据库的原理、实现方式以及SQL SERVER 2005在高可用、高性能和高保护模式下会有不同的数据库镜像状态，而且了解了SQL SERVER 2005在不同应用模式下故障转移的方式。接下来，我们将根据以下两类事件对数据库镜像预期的可用性进行分析：
一个或多个服务器或者数据库失� ......
