Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Sql Server int vs nvarchar comparison on performance?

For you database design/performance gurus out there.

I'm designing a table, I have the choice of either use int or nvarchar (128) for a column, assume space is not a problem. My question is which will give performance

when I search with int column

where ID = 12324

or when I search with nvarchar column (the Key is the entire value, so I'm not using LIKE operator)

where Key = 'my str'

I'm sure for smaller datasets it doesn't matter, but let's assume this data will be in the millions of rows.

like image 734
Ray Avatar asked Jul 19 '10 19:07

Ray


People also ask

Which is faster VARCHAR or NVARCHAR?

Therefore, In SQL Server, you should utilize NVARCHAR rather than VARCHAR. If you do use VARCHAR when Unicode support is present, then an encoding inconsistency will arise while communicating with the database.

When should I use NVARCHAR in SQL Server?

Use nvarchar when the sizes of the column data entries vary considerably. Use nvarchar(max) when the sizes of the column data entries vary considerably, and the string length might exceed 4,000 byte-pairs.

Can NVARCHAR take numbers?

NVARCHAR is a locale-sensitive character data type that allows storing character data in variable-length fields as strings of single-byte or multibyte letters, numbers, and other characters supported by the code set of the necessary database locale.

What is difference between Nchar and NVARCHAR?

The NCHAR data type is a fixed-length character data type that supports localized collation. The NVARCHAR data type is a varying-length character data type that can store up to 255 bytes of text data and supports localized collation.


2 Answers

INT will be faster - here's why:

  • SQL Server organizes its data and index into pages of 8K
  • if you have an index page with INT key on it, you get roughly 2'000 INT entries
  • if you have NVARCHAR(128) and you use on average 20 characters, that's 40 bytes per entry, or roughly 200 entries per page

So for the same amount of index entries, the NVARCHAR(128) case would use ten times as many index pages.

Loading and searching those index pages will incur significantly more I/O operations.

So to make things short: if you can, always use INT .

like image 81
marc_s Avatar answered Oct 18 '22 08:10

marc_s


Space is always a problem in databases. Wider keys mean less entries per page, more pages scanned to aggregate and sum values, means more IO, less performance. For clustered indexes, this problem gets multiplied by each non-clustered index, as they have to reproduce the lookup key (clustered key) in their leafs. So a key of type nvarchar(128) will almost always be worse than an INT.

On the other hand, don't use an INT key if is not appropriate. Always use the appropriate key, considering your queries. If you always going to query by an nvarchar(128) column value, then is possibly a good clustered key candidate. If you're going to aggregate by the nvarchar(128) key, then is likely a good clustered key candidate.

like image 42
Remus Rusanu Avatar answered Oct 18 '22 07:10

Remus Rusanu