科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道SQL Server执行SQL语句时内存占用特点

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

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

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

作者:论坛整理 superhasty 来源:天新网 2008年4月23日

关键字: 数据库 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这样的语句,在有聚集索引情况下,只会将最终记录所在的页读入内存。

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章