SQL Server Performance

How bad are clustered indexes using a varchar column?

Discussion in 'T-SQL Performance Tuning for Developers' started by ZLA, Jun 19, 2008.

  1. ZLA New Member

    In general, I've seen a comment that varchar columns don't make efficient index columns. However, I have a customer material table which has two main columns, one an integer and the other a varchar. The integer is the customer ID and the varchar is the material description. When a range of materials is required, it would generally be each customer's materials in alphabetic order.
    Would a clustered index on description, customer ID be a good or a bad idea?
    Thanks in advance.
  2. techbabu303 New Member

    Try this
    Method 1:
    Unique Clustered Index on integer column which in you case in id, remember you can create only one clustered index , I assume your integer id column has unique values.
    Create non clustered index on varchar column since it is part of range query.
    Check the execution plan for the above.
    Method 2:
    If the integer column has lot of duplicates but combination with varchar column is unique , then you can create non clustered index with both combination
    Again check the execution plan
    Next time you can save time by reviewing the posts on index tuning in this forum which are useful and can be used as guide or reference, it has helped me save crucial time to make decisions.
  3. ZLA New Member

    Thanks for the reply. I did look in the other posts but none answered my question.
    The integer ID is not unique. I should have said there are actually three main columns: an integer Identity primary key, an integer Customer ID and the varchar Description. I assume an index on Description, Customer ID would be useful. My question is whether or not a clustered index on those fields (Description, Customer ID) would be better or if using the varchar Description field is, in general, too inefficient. The Description field has an average length of 25 characters.
    Thanks again.

Share This Page