We’re suffering some heavy table locking issues in production. I have noticed that I created a stored procedure which gets a list of orders by order number. Order number is a VARCHAR(150). There is no index of any type on this column.
At the moment, there is a LOT of NULL values in this column. However, over time (This table went live recently), the table will grow significantly. No more NULL values will be added in this time.
My question is two fold. Firstly, would an index be beneficial here. The proc is heavily used. And if so, should it be clustered or not? Data is things like CP123456, DR126512.
The second question, which probably influences the first question is – would it be beneficial to change the column to a CHAR(10), as it ‘seems’ the order number is always the same size. Is there any speed benefit in putting an index on a fixed length CHAR, as opposed to a VARCHAR(150)?
(The different in size is because of unknown requirements when the column was created).
SQL Server 2008.
Yes, absolutely! Go right ahead and add an index. Clustering the index is probably unnecessary here, and will not be possible anyway if you already have another clustered index (such as the primary key) on the table.
Changing the column to a
CHAR(10)might have some benefits in terms of storage size, but it’s unlikely to make a particularly great difference in index performance. I’d skip it for now.