当前位置: 首页 > 图文教程 > 数据库 > MSSQL > SQL Server查询过程中 实际消耗了多大内存?

MSSQL
修复断电等损坏的SQL 数据库
SQL 返回期间内的所有日期
数据库中的内容字段被挂马的替换方法 SQL注入
同一个sql语句 连接两个数据库服务器
SQL Server 空值处理策略[推荐]
sql2005 create file遇到操作系统错误5拒绝访问 错误1802
SQL SERVER 删除重复内容行
SQL SERVER 的SQL语句优化方式小结
数据库高并发情况下重复值写入的避免 字段组合约束
一个有趣的SQL命题 用一条语句切换BIT型的真假值
AspNetPager分页控件 存储过程
SQL Server自动生成日期加数字的序列号
远程连接局域网内的SQL Server 的方法
把数据批量插入具有Identity列的表的方法
SQL Server 索引维护sql语句
从两种SQL表连接写法来了解过去
SQLServer 循环批处理
从每个分类选择10条记录的sql语句
SQLServer XML查询快速入门(18句话)
被遗忘的SQLServer比较运算符谓词

MSSQL 中的 SQL Server查询过程中 实际消耗了多大内存?


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-09-30   浏览: 94 ::
收藏到网摘: n/a

 或许在应用程序代码中找到的最常见的错误就是这样的查询请求:它不是使用准备好的查询或程序,而是使用非参数特设的查询从数据库中请求数据。

  不准备你的查询或者不使用存储过程会增加不必要的SQL Server计划缓存。什么是计划缓存呢?简单地说,它是SQL Server共享内存池的一部分,在这里,解析、编译和执行优化这些查询之后,查询执行计划仍被保存。无论何时执行一个查询,内存的这个区都会被查找,以便确定现有的一个计划是否可以重新使用来满足一个查询请求。重新使用计划为数据库引擎节约了潜在的CPU密集工作,例如,如果唯一的不同点是WHERE从句中正在使用的值,我们不得不一次又一次重新解析,重新编译,重新优化查询。这将导致查询响应时间加快,服务器中的CPU压力降低。

  下面的Java代码片断提出一系列非参数特设查询到AdventureWorks数据库中,以此来获得用户销售订单数据。它通过循环,从AdventureWorks SalesOrderHeader表中前20张订单中获得信息。

  

  图一

  让我们用SQL Server 2005 DMVs来检验计划缓存中特设查询的效果。


  select qs.usecounts, cacheobjtype, objtype, qt.text
  from sys.dm_exec_cached_plans qs
  cross apply sys.dm_exec_sql_text(qs.plan_handle) as qt
  order by qt.text
  go

  运行查询之后,我们可以从下面的图中看到,每一个查询执行都在内存中存储了一个非常具体的计划,该计划没有参数化,也没有被数据库引擎重新利用。因为这些计划是如此的具体,所以任何这些计划能够被重新使用的可能性很小。很容易看到,如果这是一个使用频率非常高的应用程序,那么服务器内存会很快地消耗。

  

  图二

 现在将调整Java代码来准备这个查询语句。在执行之前,我通过命令DBCC FREEPROCCACHE清除该计划缓存,接着通过一个准备好的语句重新运行java class

  

  图三

  重新审视这个计划缓存,我们可以看到,该查询已经成功编译并且重新用于所有的执行,因此有效地使用和保存服务器内存和限制CPU使用。

  

  图四

  现在,考虑到由于计划缓存是内存共享池的一部分,那么消除多余的计划可以为其他缓存腾出更多可用内存,从而使其他的缓存可以使用这个共享池,比如存储已经从硬盘中读取到内存中的数据和索引页的SQL Server数据缓存。

  虽然相对于使用非参数特设的查询请求来说,准备好的查询是一种更好的方法,但是比起这两种方法,我个人更偏向于使用存储过程。允许直接访问你的核心数据库表存在安全风险,通过存储过程把数据从逻辑中抽取出来可以减少维护,并且当业务需求变化时,它也能够减少数据模型的变化。无论你选择哪种数据访问方法,请记住通过确保你的查询计划是可以重复利用的,从而把你的应用程序从潜在的内存和CPU问题中解救出来。