Can anyone provide any concrete evidence of performance when comparing
int = int
and:
string = string
in
Put both of your queries in the same query window. At the very top (before either of these queries) put: SET STATISTICS IO ON
When you run the code run it with the option "Include Actual Execution Plan" (an icon on your toolbar which looks like three little boxes, about 7 icons to the right of the Execute button)
This will result in three tabs in your results: Results, Messages, Plan. The Messages and the Plan will show you the IO cost and the full Execution cost.
The query with the bigger numbers has the highest cost! This method will allow you to prove to yourself which query has the lowest cost (highest performance)
As Steve pointed out in the comments, the presence and constitution of indexes will greatly impact your results; however, since SQL Server works with pages to lookup data, and narrower column types can store more data per page, using a narrow type can perform better than a wider type where there are more values to consider.
So, if you have a small table (few rows), it probably doesn't matter; big table? Put an index on the int column and it will probably out-perform an indexed varchar column.
Of course, what constitutes large or small tables depends on your hardware.
OK interesting question always took it as read that integer was quicker and never actually tested it. I took 1M Random Surnames and types from a list of Contacts from my data into a scratch database with no indices or primary key just raw data. No measurement was made over the range of my data in either of the columns has not been standardised so reflects the reality of my database rather than a pure statistical set.
select top 100 * from tblScratch where contactsurname = '<TestSurname>' order by NEWID()
select top 100 * from tblScratch where contacttyperef = 1-22 order by NEWID()
The Newid is there to randomise the data list out each time. Quickly ran this for 20 surnames and 20 types. Queries were run surname than ref then surname. Searching for the reference number was almost 4x quicker and used about 1/2 so the books were right all those years ago.
String -
SELECT TOP 100 * FROM tblScratch WHERE contactsurname = 'hoare' ORDER BY NEWID()
Duration 430ms
Reads 902
CPU 203
Integer -
SELECT TOP 100 * FROM tblScratch WHERE contacttyperef = 3 ORDER BY NEWID()
Duration 136ms
Reads 902
CPU 79
Comparing integers should be faster, at the very low level it will end up with 1 cmp
instruction. Comparing string involves more instructions, and as a result, worse performance.
I assume you either have or don't have indexes on both fields, indexes are equally selective, number of records also the same