Scribd
Upload
96 views

Convert Implicit and The Related Performance Issues With SQL Server

The document describes a performance issue when querying a SQL Server database table. When filtering on the primary key column, which was defined as a character string but stored numeric values, the queries performed a full table scan instead of an index seek. This was caused by SQL Server implicitly converting the character string column to a number when comparing it to the numeric filter value. Changing the filter to use a string value instead resolved the issue and allowed the more efficient index seek.

Uploaded by

carlos
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
96 views

Convert Implicit and The Related Performance Issues With SQL Server

The document describes a performance issue when querying a SQL Server database table. When filtering on the primary key column, which was defined as a character string but stored numeric values, the queries performed a full table scan instead of an index seek. This was caused by SQL Server implicitly converting the character string column to a number when comparing it to the numeric filter value. Changing the filter to use a string value instead resolved the issue and allowed the more efficient index seek.

Uploaded by

carlos
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Convert Implicit and the related

performance issues with SQL Server


Problem
I was a running a routine query using an equal operator on the only column of the
primary key for a table and I noticed that the performance was terrible. These
queries should have been flying because all I was doing was retrieving one row of
data which should have been doing an index seek. When I looked at the query plan
it was doing a scan instead. This tip shows you what I found and how to resolve
the problem.
Solution
The problem I was facing can be seen by doing a similar query in the SQL Server
2005 AdventureWorks database on the HumanResources.Employee table. To help
us understand what SQL Server is doing when we run these queries, let's ask for IO
statistics and also use the SSMS menu command Query\Include Actual Execution
Plan.
To use the AdventureWorks database and turn on IO statistics, start with this
query:
use AdventureWorks
go
SET STATISTICS IO ON
go
Here's a query on the Employee table which is similar to the ones that caused me
so much difficulty:
SELECT EmployeeID, NationalIDNumber, LoginID
FROM HumanResources.Employee
WHERE NationalIDNumber = 112457891
go
It seems pretty innocuous. The HumanResources.Employee table has an index that
begins with NationalIDNumber so executing the query should just be a matter of
seeking to the location of 112457891 and then doing a lookup to get the table row.
But the statistics and the query plan show otherwise. Here are the messages:
EmployeeID NationalIDNumber LoginID
----------- ---------------- ---------------------4 112457891
adventure-works\rob0
(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)

The statistics show 1 scan and that's the problem.


Adventureworks.HumanResources.Employee only has 291 rows, so this probably
ran really fast and doesn't seem like a problem. The table that I was working on
had millions of rows and the table scan was a killer taking several seconds for each
query..
Since the NationalIDNumber column is at the start of an index and the only column
for this index, why was there a scan and not a seek? The query plan below tells us
why. Here's the overall plan where you can see the index scan:

The tool tip for the index scan gives the details that make all the difference, as
shown below.

The red arrow points to the problem. The function call CONVERT_IMPLICIT(int,
[AdventureWorks].[HumanResources].[Employee].[NationalIDNumber, 0) is
modifying the NationalIDNumber column before it is compared to the integer
constant 1124579811 which we are passing into this query. If you look at the table
definition you'll see that NationalIDNumber is declared to be nvarchar(15). Once
there is a function, even an implicit one as we see here, used on the column SQL
Server can't use the index on NationalDNumber and it falls back on a scan.
Changing the query to compare to a string constant and the problem goes away:
SELECT EmployeeID, NationalIDNumber, LoginID
FROM HumanResources.Employee
WHERE NationalIDNumber = '112457891'
go
The messages now shows that there are zero scans, which is what we want. In this
case the difference in logical reads is only 2, that's because the Employee table is
so small. Working with a million row table, the difference in logical reads grows
into the thousands.
EmployeeID NationalIDNumber LoginID
----------- ---------------- ---------------------4 112457891
adventure-works\rob0
(1 row(s) affected)
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.

(1 row(s) affected)

The query plan shows the seek and the key lookup which is what we would have
expected to occur.

This problem is common where a character string has been used to store a numeric
key. SQL Server will dutifully perform the implicit conversion and return the correct

result, but at the cost of poor performance by doing a scan instead of a seek and
using the index correctly.
Next Steps

Always be alert for implicit conversions, particularly when there are


character strings storing numeric keys.

I've even seen this problem when varchar columns are compared to
nvarchar columns.

Fixing the problem is straight forward, just make sure you are performing
the comparison on like data types.

You might also like