SQL Server数据库的相关性能问题与隐式转换

数据库 SQL Server
此文章主要向大家讲述的是正确的隐式转换与SQL Server数据库的相关性能问题,以下就是文章的主要内容的详细描述。

此文章主要向大家描述的是正确的隐式转换与SQL Server数据库的相关性能问题,面临的问题可以对其通过在HumanResources.Employee表的SQL Server 200***dventureWorks数据库中做一个类似的查询来看到。

为了帮助我们更好地理解SQL Server在我们运行这些查询时都做了什么,让我们来查找IO统计数据,

 

我面临的问题可以通过在HumanResources.Employee表的SQL Server 200***dventureWorks数据库中做一个类似的查询来看到。为了帮助我们更好地理解SQL Server在我们运行这些查询时都做了什么,让我们来查找IO统计数据,并且使用SSMS菜单命令Query\Include Actual Execution Plan。

 

为了使用AdventureWorks数据库并且启用IO统计数据,让我们从下面的查询开始:

  1. use AdventureWorks   
  2. go  
  3. SET STATISTICS IO ON  
  4. go  

 

这是对Employee表的一个查询,它类似于给我带来上述麻烦的查询:

 

  1. SELECT EmployeeID, NationalIDNumber, LoginID   
  2. FROM HumanResources.Employee  
  3. WHERE NationalIDNumber = 112457891 
  4. go  

 

 

它看起来似乎不会给我们带来什么麻烦。HumanResources.Employee表有一个以NationalIDNumber开始的索引,因此执行这个查询只是查找112457891的位置然后对这个表的行作查找。但是统计数据和查询计划显示了事情并非如此简单。这是相关的信息:

 

  1. EmployeeID NationalIDNumber LoginID   
  2. 4 112457891 adventure-works\rob0  
  3. (1 row(s) affected)  
  4. Table 'Employee'. Scan count 1, logical reads 6,  
  5. physical reads 0, read-ahead reads 0,  
  6. lob logical reads 0, lob physical reads 0,  
  7. lob read-ahead reads 0.  
  8. (1 row(s) affected)  

 

该统计数据显示有一个扫描,而这正是问题所在。Adventureworks.HumanResources.Employee只有291行,因此这可能真的可以很快地运行并且看似不会造成什么问题。我使用的表有数百万行,表扫描正是凶手,因为它对于每次查询都要花几秒的时间。

 

由于NationalIDNumber字段在索引以及该索引***字段的开头,那么为什么这里只有一个扫描而没有查找呢?下面的查询机坏昂告诉我们为什么。这是你可以看到索引扫描的整个计划:

该索引扫描的工具技巧给出所有不同点的详细信息,如下所示:

红色箭头指向了该问题。函数CONVERT_IMPLICIT(int, [AdventureWorks].[HumanResources].[Employee].[NationalIDNumber, 0)在它与我们传递到该查询中的整数常数1124579811比较之前修改了NationalIDNumber字段。如果你查看这张表的定义,那么你就会看到NationalIDNumber被定义成nvarchar(15)。一旦这里有个函数,即使是我们在这里看到的自带函数用于这个字段,SQL Server数据库都不能在NationalDNumber上使用索引,它会返回到一个扫描中。

更改这个查询来与一个字符串常数比较,这个问题将得到解决:

  1. SELECT EmployeeID, NationalIDNumber, LoginID   
  2. FROM HumanResources.Employee  
  3. WHERE NationalIDNumber = '112457891' 
  4. go  

 

 

这些信息现在显示为零扫描,这正是我们想要的。在这个案例中,逻辑读的不同点是只有2,这是因为Employee很小。如果在数百万行的表上进行这个过程,那么逻辑读的不同点将变成几千。

 

  1. EmployeeID NationalIDNumber LoginID   
  2. 4 112457891 adventure-works\rob0  
  3. (1 row(s) affected)  
  4. Table 'Employee'. Scan count 0, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.  
  5. (1 row(s) affected)  

 

 

查询计划显示查找和主键查找正是我们希望看到的。

 

一个字符串用于存储一个数字型主键的问题是很常见的。SQL Server数据库将很忠实地执行隐式转换并返回正确的结果,但是要以较差的性能为代价,通过一个扫描而不是查找来进行并且要正确使用该索引。

下一步

要一直警惕隐式转换,尤其是有存储数字型键的字符串的时候。

我甚至在varchar字段与nvarchar字段进行比较的时候看到这个问题。

更正这个问题是很简单的,你只需要确保在相似的数据类型上执行比较。

 

【编辑推荐】

  1. SQL Serverlink Oracle的几种不同方式
  2. SQL Server Compact中的DLL文件与工具
  3. SQL Server数据库在安装时的注意事项
  4. SQL Server 2005 Express混合模式登录的设置
  5. SQL Server 2005数据库安装实例演示

 

责任编辑:佚名 来源: 博客园
相关推荐

2010-04-07 09:31:02

Oracle数据库

2010-07-05 13:36:21

SQL Server

2021-03-04 22:02:18

SQL Serve数据库架构

2019-09-06 08:22:20

MySQL数据库索引

2021-03-24 14:50:00

SQLServer数据库字符串

2021-03-19 07:12:23

SQL Server数据库数据库收缩

2010-07-23 15:03:02

SQL Server数

2010-06-29 16:41:24

SQL Server分

2022-02-23 21:24:21

索引SQL字符

2010-07-01 11:14:36

SQL Server

2010-06-17 13:34:47

SQL Server数

2011-04-01 14:05:09

SQL数据库

2010-07-15 17:28:50

SQL Server

2010-08-17 09:22:34

2010-07-21 10:15:43

SQL Server

2011-08-04 15:20:52

SQL Server数据库镜像

2010-07-07 14:24:42

SQL Server

2011-04-06 16:15:21

SQL Server数简体繁体

2010-07-16 15:53:19

SQL Server数

2011-01-19 09:51:25

SQL Server
点赞
收藏

51CTO技术栈公众号