SQL Server执行SQL语句时内存占用特点

来源:互联网 发布:java百度云资源 编辑:程序博客网 时间:2024/05/02 15:03

SQL Server执行SQL语句时内存占用特点

本文关键词:数据库 Mssql SQL SQL Server

众所周知,SQL Server执行SQL语句的性能判定标准主要是IO读取数大小。本文在不违反这一原则情况下,同时来分析一下部分SQL语句执行时,SQL Server内存的变化情况。

首先简述一下SQL Server内存占用的特点。SQL Server所占用的内存除程序(即SQL Server引擎)外,主要包括缓存的数据(Buffer)和执行计划(Cache)。SQL Server以8KB大小的页为单位存储数据。这个和SQL Server数据在磁盘上的存储页大小相同。当SQL Server执行SQL 语句时,如果需要的数据已经在其内存中,则直接从内存缓冲区读取并进行必要的运算然后输出执行结果。如果数据还未在内存中,则首先将数据从磁盘上读入内存Buffer 中。而我们通常评价SQL性能指标中的IO逻辑读取数对应的正是从内存缓冲区读取的页数,而IO物理读取数则对应数据从磁盘读取的页数。

注:以下的试验在多人共享的开发测试服务器上也可以进行,因为实际上可以分别看到某个表所占用的内存情况。但为了方便,笔者在做此试验时,在一个单独的、确认没有其它并发任务的数据库上进行,因此所看到的内存变化正是每一次所执行的SQL语句引起的。

我们首先来看一个简单的实例。创建下表:

以下是引用片段:
Create Table P_User
  ( UserMobileStatus int NOT NULL,
  MobileNo int NOT NULL,
  LastOpTime DateTime Not NULL
  )

然后为该表插入一定的数据:

以下是引用片段:
Declare @i int
  Set @i=28000
  WHILE @i<29000
  BEGIN
  Insert Into P_User
  Select @i % 2,@i,GetUTCDate()
  Set @i=@i+1
  END

然后我们在查询分析器中首先执行:

以下是引用片段:
Set Statistics IO ON

并按下Ctrl+M以显示实际的执行计划。

此时,可以开始进行我们的试验了。为了准确观察每一次SQL语句变化情况,在执行第一条SQL语句以前,我们首先清空SQL Server所占用的数据内存:

以下是引用片段:
CHECKPOINT
  GO
  DBCC DROPCLEANBUFFERS

这将清空SQL Server所占用的数据缓冲区(此语句在生产服务器上慎用,因为将导致一段时间内后续的SQL语句执行变慢)。

测试1:在没有索引的表上执行SQL语句

1.1 执行全表选取或者低选择性选取

Select * From P_User

从SQL执行计划可以看到,由于此时表中没有任何索引,因此将产生Table Scan。而IO统计结果如下:

(1000 row(s) affected)

表'P_User'。扫描计数1,逻辑读取4 次,物理读取4 次,预读0 次,lob 逻辑读取0 次,lob 物理读取0 次,lob 预读0 次。

我们看一下数据库内存中的情况。

首先查询到我们所操作database的database_id:

以下是引用片段:
Select database_id From sys.databases Where name='TestGDB'

然后使用该database_id从表中查看内存情况:

以下是引用片段:
SELECT * FROM sys.dm_os_buffer_descriptors bd
  WHERE database_id=5
  order by allocation_unit_id,page_id

SQL Server执行SQL语句时内存占用特点

ZDNet 软件频道 更新时间:2008-04-23 作者:论坛整理 superhasty 来源:天新网

本文关键词:数据库 Mssql SQL SQL Server

得到结果如下:

  

得到的结果中可以看到,除了必要的管理页(一个PFS_Page和一个IAM_Page)外,内存中总共出现了4个Data_Page页。这和刚才IO统计中看到的结果:逻辑读为4,物理读为4相同。由于是全表读取,表明P_User表全部数据所占用的数据页数也正是4,将这4个数据页的row_count数加起来也可以验证其总数据行=1000。

在上例中,如果不清空数据缓冲区,再执行一遍SQL,可以看到内存毫无变化,而逻辑读也不变,只是物理读变为0,因为已经不需要再从磁盘读入数据。

1.2 执行高选择性选取

另外,在没有索引的情况下,如果将上例修改为:

以下是引用片段:
Select Top 1 * From P_Order 或者Select * From P_Order Where MobileNo=28502

可以看到,系统同样要读取全部的数据页到内存。

如果使用Select Top 1 * From P_Order Where MobileNo=28502这样的选取方式,有可能会出现只读取部分数据页到内存的情况。但由于在没有索引情况下,数据实际上是无序存放在堆上,所以结果很不稳定,也有可能发生读取所有的数据页到内存。

测试2:建立聚集索引情况下,执行SQL语句

2.1 执行全表选取或者低选择性选取

修改表结构,在MobileNo字段上建立聚集索引。然后再次执行刚才的SQL语句。得到的执行计划变为聚集索引扫描。IO统计消息为:

(1000 row(s) affected)

表'P_User'。扫描计数1,逻辑读取6 次,物理读取1 次,预读4 次,lob 逻辑读取0 次,lob 物理读取0 次,lob 预读0 次。

这里的逻辑读取变为6次。

内存情况如下:

  

内存中的变化是增加了一个非叶级的聚集索引页,而叶级的聚集索引则会和数据放在一起。

另外,可以查看该表索引的级别:

以下是引用片段:
 SELECT database_id,object_id,index_id,index_level,page_count,record_count
  FROM sys.dm_db_index_physical_stats
  (DB_ID(N'TestGDB'), OBJECT_ID(N'dbo.P_User'), NULL, NULL , 'DETAILED');

从结果可以看到该表的聚集索引总共分2级。

  

因而逻辑读增加了2——(由于发生Clustered Index Scan,除了根级别的聚集索引页占用1次外,从根级别聚集索引定位到叶级别的聚集索引也将额外占用1次逻辑读)。

另外一个变化是只发生了一次物理读,即读取根级别的聚集索引页,另外4个数据页则通过预读方式而不是物理读从磁盘装入内存Buffer。这使得有聚集索引的情况下,执行SQL所直接花费的代价实际上更小。

2.2 执行高选择性选取

在建立聚集索引情况下,对性能有益的变化是:

对于Select Top 1 * From P_Order 或者Select * From P_Order Where MobileNo=28702这样的语句,在有聚集索引情况下,只会将最终记录所在的页读入内存。

测试3:建立非聚集索引情况下,执行SQL语句

3.1 执行全表选取或者低选择性选取

如果将表中同一字段的聚集索引换成非聚集索引,则可以看到如下特点:

执行全表扫描将和没有任何索引的情况相似,将读取所有的数据页到内存。此时,SQL Server的查询引擎实际上无法使用非聚集索引。

3.2 执行高选择性选取

将只读取最终数据所在的页到内存。通过查询计划可以看到,SQL Server在非聚集索引上使用INDEX SEEK,然后通过lookup 得到数据实际所在行(索引覆盖情况下例外,因为不需要定位到实际数据行)。

测试4:执行Nested Loop Join

在进行测试前,我们先准备另外一张表和数据。

以下是引用片段:
 Create Table P_Order
  ( UserStatus int NOT NULL,
  MobileNo int NOT NULL,
  Sid int Not NULL,
  LastSubTime DateTime
  )

插入数据:

以下是引用片段:
Declare @i int
  Set @i=20000
  WHILE @i<30000
  BEGIN
  Insert Into P_Order
  Select @i % 2,@i,@i-19999,GetUTCDate()
  set @i=@i+1
  END

可以看到,在执行全表扫描情况下,该表10000条数据总共占用38个内存数据页。

4.1 执行全表选取或者低选择性选取

以下是引用片段:
Select * From P_Order A
  Inner Loop JOIN P_User B ON A.MobileNo=B.MobileNo

对于此种高选择性选择,默认情况下SQL Server不会执行Loop Join。因此,使用了强制性的联接提示。

在两个表都没有任何索引的情况下,可以看到:

两个表所有的数据页都将被加载到内存。逻辑读取代价高达6万多次——对于P_Order表中的每一条记录,都将在P_User表中进行遍历。

在其中一个表有聚集索引情况下,尽管逻辑读取相比刚才的6万多次已经大大下降,但仍然达到2万次。而且联接的次序对查询性能影响很大。因为其实际执行的是将SQL语句中前面的表作为联接的外部输入,而后面的表作为联接的内部输入。

在两个表都有聚集索引情况下,相比较而言,逻辑读仍然达到数千次(取决于最终输出的数据大小),但相比较已经大大改善。而且表中的数据只有最终需要输出的部分才会被读入内存Buffer中。

4.2 执行高选择性选取

执行如下的SQL语句:

以下是引用片段:
 Select * From P_Order A
  Inner merge JOIN P_User B ON A.MobileNo=B.MobileNo
  Where A.MobileNo=28913

在两个表都没有任何索引情况下,两张表都将执行全表扫描。要读入所有的数据页到内存。总体逻辑读取决于两表的数据页数。

在一个表有聚集索引或者非聚集索引情况下,该表将执行Index Seek,另一个表将出现全表扫描。内存数据缓冲区中,将有一张表只读入最终数据所在的数据页、一张表读入全部数据页。逻辑读数取决于表在联接中的秩序、以及无索引表的数据页数。

在两个表都有聚集索引情况下,逻辑读最小,每个表只有2到3次。而且只有实际需要输出的数据才会被读入内存页。两个表都有非聚集索引情况下,消耗的逻辑读和内存资源近似。

原创粉丝点击