Hi Andy,
This has got me bugged.

I have searched high and low and I can't find any reference to query performance being hindered using varchar vs. char. I found a lot of references stating that updates to the table may be slower (perceptible or not is another conversation) because the updates may be deferred (separate delete and insert). If the size of the data changes, the data has to be moved to another part of the page or to a new page entirely and this adds performance overhead. If the data is the same length, an in-place update can take place.

The same performance hit for maintenance would most likely also be seen for indexes. However, reading the indexes and comparing values for a WHERE or JOIN condition is not mentioned.

Did you see your performance hits in yoru queries or your transactions?

>Hi Larry
>
>>Why is CHAR faster than VARCHAR? Have you run tests on this yourself? Or did you see an article by someone who did? I'm curious.
>
>If you check the SQL Server Books OnLine you will find the following statement under the help for "char and varchar"
>
>

Use char when the data values in a column are expected to be consistently close to the same size.
>

Use varchar when the data values in a column are expected to vary considerably in size.
>
>No specific reason is given for these statements in this screen, but if you then read around the indexing stuff you will find reference to the fact that indexes on fixed width columns are more efficient and more easily maintained than variable width columns.
>
>My own experience with very large data sets would tend to confirm that this is actually the case too. Fixed width columns are much easier for the system to manage than variable width.

Larry Miller
MCSD
LWMiller3@verizon.net

Accumulate learning by study, understand what you learn by questioning. -- Mingjiao