三级头_三级据库:隐式转换以及SQLServer的相关性能问题

时间:2018-05-19  来源:安全工程师  阅读:

三级据库:隐式转换以及SQLServer的相关性能问题

  我面临的问题可以通过在HumanResources.Employee表的SQL Server 2005 AdventureWorks数据库中做一个类似的查询来看到。为了帮助我们更好地理解SQL Server在我们运行这些查询时都做了什么,让我们来查找IO统计数据,并且使用SSMS菜单命令QueryInclude Actual Execution Plan。
  为了使用AdventureWorks数据库并且启用IO统计数据,让我们从下面的查询开始:
  use AdventureWorks
  go
  SET STATISTICS IO ON
  go
  这是对Employee表的一个查询,它类似于给我带来上述麻烦的查询:
  SELECT EmployeeID, NationalIDNumber, LoginID
  FROM HumanResources.Employee
  WHERE NationalIDNumber = 112457891
  go
  它看起来似乎不会给我们带来什么麻烦。HumanResources.Employee表有一个以NationalIDNumber开始的索引,因此执行这个查询只是查找112457891的位置然后对这个表的行作查找。但是统计数据和查询计划显示了事情并非如此简单。这是相关的信息:
  EmployeeID NationalIDNumber LoginID
  ----------- ---------------- ----------------------
  4 112457891 adventure-worksrob0
  (1 row(s) affected)
  Table ’Employee’. Scan count 1, logical reads 6,
  physical reads 0, read-ahead reads 0,
  lob logical reads 0, lob physical reads 0,
  lob read-ahead reads 0.
  (1 row(s) affected)
  该统计数据显示有一个扫描,而这正是问题所在。Adventureworks.HumanResources.Employee只有291行,因此这可能真的可以很快地运行并且看似不会造成什么问题。我使用的表有数百万行,表扫描正是凶手,因为它对于每次查询都要花几秒的时间。
  由于NationalIDNumber字段在索引以及该索引唯一字段的开头,那么为什么这里只有一个扫描而没有查找呢?下面的查询机坏昂告诉我们为什么。这是你可以看到索引扫描的整个计划:  


图一

 

 

三级头_三级据库:隐式转换以及SQLServer的相关性能问题

http://m.kwkids.com/jianzhulei/8454.html

推荐访问:三级安全教育 三级医院
相关阅读 猜你喜欢
本类排行 本类最新