页

SQL Server中的页是最基本的数据单位组成，他有8KB，也就是8192个字节（mssql7.0以前是一个页面2KB），而sql server的一个页面，由页头，数据行，和slot table组成（行偏移的位置的记录数组。

页头

页头是一个固定的96字节的大小，他是一个页面的元数据，记载与本页相关的许多信息，具体的参数，大家可以参看我很久以前写的一篇文章，SQL server数据页页头参数列表，这篇文章没有太细致的对参数进行讲解，我在这里仔细说一下：

PAGEID：

页面的ID，在mssql中，唯一定位一行数据（包括索引）的，靠的是mssql里面的一个我把它称之为的三段式表达式：FPS ID，即 file id,page id,slot id。File ID 为文件ID，找到行所在的文件，pageID找到行所在的页面，slot ID为插槽ID，即这一行位于这个页面的第几个插槽。插槽的概念会在稍后提到。1:1:2表示这行数据位于第一个文件的第一个页面的第二个插槽。

Nextpage：

这个参数在页面处于页面链的时候，指示这个页面的下一个页面地址，这个的表达格式是 fileid：pageid，比如：1：2，请注意一下，这个页面指针并不是完全指向物理磁盘上的页面地址，因为外部碎片的存在！如果是堆表，那么这两个参数会是null。

objID：

在sysobjects 表内的对应的ID

Lsn：

Log sequence number ，日志序列号，他用来记录当这个页面行数据发生改变时的日志记录号，和此前版本的lsn，这个对于事务的管理非常重要，他将指示数据是否被回滚，或者被重做。

Slotcnt：

页面插槽总数。也就是这个页面有多少行。一个萝卜一个坑，一行数据一个槽。

Level：

在索引页中的级别，0为子叶节点。

Indexed：

0为普通数据页面（堆表），1为聚集索引页面，大于1都为非聚集索引。

Pminlen：

每行数据的固定长度，比如一行数据有3个int字段，1个char5的字段，2个varchar字段，那么固定长度是17.这个参数在mssql定位字段数据时起到至关重要的作用。

freeCnt：

页面空闲的字节数，在每次需要插入数据时就检测这个值，空间是否够用。

m_ghostRecCnt：

页面含有的幻影行的数目。幻影行是sql server在删除数据时，并不及时删除数据，而是仅仅将他标记为幻影行，并不对磁盘中的数据进行清空。这样做有非常大的好处。如果数据回滚，那么只需要将标记去掉即可。数据库会在空闲的时候将页面进行整理，去掉幻影行，而没有必要即时性的整理页面。

Slot table

插槽表是用于记录行在页内的逻辑顺序和物理顺序的对应数组。比如逻辑上是第一行的数据可能在这个页面内是物理上位于第二行。而这个物理上的位置，指的是在这个页面的8KB的空间内的位置，slottable有记录行的逻辑顺序数，物理顺序数，还有相对页头的偏移量，以便数据查找定位。在这里衍生的一个问题就是，逻辑上的行顺序可能存储在磁盘上的物理顺序也不会是一个顺序！（当然还有可能页面存在lob数据，成为一个页指针）

猜想：Slottable实际上是对空间的一个利用，当然也涉及到了当数据行进行增删改查时，对页面的破坏，最后在设计上导入了slot table。假设一个场景，当一个页面全部被填充满了，freecnt为0的时候，删除一个数据（页面存储100个数据，删除其中的第2个），那么如果根据正常的逻辑，应该是将2到第100行的数据全部移动，然后整理出末尾还剩一行的数据。这样现实吗？那样页面所有数据都要移动，似乎不大现实。所以mssql在设计上引入了slot table ,这样，物理上和逻辑上的顺序由slot table 映射起来，存储引擎负责向slot table 要数据位置，slot table负责映射其真正的物理位置，slottable在其中搭建起一个桥梁，降低了他们之间的耦合，使得当逻辑顺序发生变化的时候，物理位置却不需要相应的变化，哈哈，相信这个也是一个典型的设计上的解耦的例子吧～～

测试语句：

Code
set statistics io on
set statistics time on
select a.* from Production.Product a inner join Production.ProductModel b
on (a.ProductModelID = b.ProductModelID)

select a.* from Production.Product a where exists (select 'X' from Production.ProductModel b
where a.ProductModelID = b.ProductModelID)

select a.* from Production.Product a where a.ProductModelID in (select b.ProductModelID from Production.ProductModel b)

测试统计：

Code
SQL Server 分析和编译时间: 
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

SQL Server 执行时间:
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。
SQL Server 分析和编译时间: 
   CPU 时间 = 15 毫秒，占用时间 = 63 毫秒。

SQL Server 执行时间:
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

SQL Server 执行时间:
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

(9440 行受影响)
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Product'。扫描计数 1，逻辑读取 474 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'ProductModel'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

SQL Server 执行时间:
   CPU 时间 = 63 毫秒，占用时间 = 1984 毫秒。

(9440 行受影响)
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Product'。扫描计数 1，逻辑读取 474 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'ProductModel'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

SQL Server 执行时间:
   CPU 时间 = 78 毫秒，占用时间 = 1780 毫秒。

(9440 行受影响)
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Product'。扫描计数 1，逻辑读取 474 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'ProductModel'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

SQL Server 执行时间:
   CPU 时间 = 109 毫秒，占用时间 = 1366 毫秒。
SQL Server 分析和编译时间: 
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

SQL Server 执行时间:
   CPU 时间 = 0 毫秒，占用时间 = 1 毫秒。

执行计划

可以看到无论是查询计划还是统计IO，都是一样的。

这都是优化器的功劳，并不存在哪个谓词就好些，除非你的测试环境是2000以下。

Code
set statistics io on
set statistics time on 
   SELECT TOP 10 FeedBackID,UserID,ContentID,[Content],  
   Time,AddType,IP  FROM   CYZoneFeedBack  
   where contentid in (select articleid from cyzonearticle where userid=@user and delflag=0 and publishtype<>'b')
    and CYZoneFeedBack.DelFlag =0 order by CYZoneFeedBack.Time desc

分析是这样的：

原来是排序造成了这么多开销。罪魁祸首在于 order by CYZoneFeedBack.Time 这句话，后改成：

Code
set statistics io on
set statistics time on 
   SELECT TOP 10 FeedBackID,UserID,ContentID,[Content],  
   Time,AddType,IP  FROM   CYZoneFeedBack  
   where contentid in (select articleid from cyzonearticle where userid=107and delflag=0 and publishtype<>'b')
    and CYZoneFeedBack.DelFlag =0 order by CYZoneFeedBack.feedbackid desc

执行计划变为：

很明显省掉了排序的操作。有时候，排序和时间是有相关性的，而聚集索引，没有建在时间上，会导致排序成本的增加，恰当的利用自增ID来做时间排序，也能省掉很多开销。

目前已经没有了，我总结了一下，问题应该是出现在连接串内使用了持久化安全性和windows验证这2个选项，这个选项导致在有其他应用程序在审核失败后，其安全性可能又被数据库延续了下来，所以导致失败。在修改连接串后数据库恢复正常。

Code
select a.name,b.text from sys.sysobjects a inner join syscomments b
on a.id = b.id and b.text like '%你要找的字符串%'

方法二：

刚在外文资料上看到的：

Code
--Declare whatever you can :)
Declare @SString nvarchar(50)
Declare @getdbname sysname
Declare @sqlstm nvarchar(1000)
Declare dbname cursor for 

--get all the names of the Databases in order by name
Select '['+name+']' from master.dbo.sysdatabases order by name 
open dbname

--Get the first Name
FETCH NEXT FROM dbname into @getdbname

WHILE @@FETCH_STATUS=0
BEGIN

--set the search string
SET @SString = '<Place the String Here>'

--append the search pattern
SET @SString = '%' + @SString + '%'

--set the statement to define the search condition, with variables
SET @sqlstm = '
Select Specific_Catalog as Database_Name, Routine_Name as ''Stored Procedure Name'',Routine_Definition 
From '+ @getdbname+'.Information_Schema.Routines 
Where PatIndex('+''''+@SString+''''+', Routine_Definition) > 0'

--Execute the Query
EXEC (@sqlstm)
FETCH NEXT FROM dbname into @getdbname
END

--Close the Cursor and Deallocate it from memory
Close dbname
Deallocate dbname 

（出处：http://www.sqlservercentral.com/scripts/Search/63397/）

第二个用的cursor查找，所有库的，二者范围不一样。

供大家急需时参考。