• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 699
  • Last Modified:

Pros and Cons of Composite Clustered Indexes

We have a Datawarehouse table with the following Primary Key and associated Clustered Index:

ALTER TABLE [dbo].[PosSaleTransactionDerivedCategory] ADD  CONSTRAINT [PK_PosSaleTransactionDerivedCategory] PRIMARY KEY CLUSTERED
(
      [PK_PosSaleTransactionDerivedCategory] ASC,
      [OutletID] ASC,
      [CompanyID] ASC,
      [DateID] ASC,
      [DistrictID] ASC,
      [Shop1SupplierID] ASC,
      [Shop2SupplierID] ASC,
      [DesignID] ASC,
      [TypeID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

1) Given that PK_PosSaleTransactionDerivedCategory is and IDENTITY field that auto-increments by 1, is there any point having all of these fields as part of the primary key?

2) Given that PK_PosSaleTransactionDerivedCategory is and IDENTITY field that auto-increments by 1, is there any point having all of these fields as part of the clustered index?

3) Does the sequence of the fields in the clustered index matter from a performance point of view? (Note that there is a significant difference in the cardinality of each of the fields above, with DateID having a very high cardinality and TypeID having fewer than 10 distinct values.)

0
batbertram
Asked:
batbertram
1 Solution
 
batbertramAuthor Commented:
Quick remarks:

The table has 20m rows.

DateID does currently have the highest cardinality (500 distinct values) but it is likely that OutletID will ultimately have a higher cardinality.

Often queries will be dealing with a DateID range while they will never deal with a range over any of the other fields.
0
 
lluddenCommented:
There is a good article on MSDN about clustered indexes: http://msdn.microsoft.com/en-us/library/aa933131%28v=sql.80%29.aspx

The important parts based on your question are:
Clustered indexes are not a good choice for:
    * Columns that undergo frequent changes - This results in the entire row moving (because SQL Server must keep the data values of a row in physical order). This is an important consideration in high-volume transaction processing systems where data tends to be volatile.
    * Wide keys - The key values from the clustered index are used by all nonclustered indexes as lookup keys and therefore are stored in each nonclustered index leaf entry.

I personally would look seriously at making the Clustered index just with the DATEID field.  Having such a complete clustered index is going to make inserts very expensive, and you may have more space used by indexes than by the data itself.

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now