Suspect Duplicate Index/Key

  • Ok. I'm in need of some opinions here. Ran the sp_BlitzIndex tools on a suspect server at a new job. I'm getting a number of these types of "borderline duplicate keys". Generally I'd find these a bit more obvious, but the whole system seems to be setup this way so I'm hesitant.

    First off, they're not using a uniqueidentifier field, but a varchar(36) to store a GUID. That's not my issue but just a side note of "this is already odd". Following is the sample from 1 table.

    Details: schema.table.index(indexid):dbo.AccountAddresses.IX_AccountAddresses_Account (1)

    Definition: [Property] ColumnName {datatype maxbytes}:[CX] [1 KEY] AccountID {varchar 36}

    Secret Columns:[UNIQUIFIER]

    Usage:Reads: 53,100 (52,911 seek 189 lookup) Writes:0

    Size:13,165 rows; 0.6MB

    Create TSQL:CREATE CLUSTERED INDEX [IX_AccountAddresses_Account] ON [dbo].[AccountAddresses] ( [AccountID] ) WITH (FILLFACTOR=100, ONLINE=?, SORT_IN_TEMPDB=?);

    Details: schema.table.index(indexid):dbo.AccountAddresses.PK_AccountAddresses (2)

    Definition: [Property] ColumnName {datatype maxbytes}:[PK] [2 KEYS] AccountID {varchar 36}, AddressID {int 4}

    Secret Columns:[1 INCLUDE] AccountID {varchar 36} [UNIQUIFIER]

    Usage:Reads: 192 (189 seek 3 scan) Writes:0

    Size:13,165 rows; 0.5MB

    Create TSQL:ALTER TABLE [dbo].[AccountAddresses] ADD CONSTRAINT [PK_AccountAddresses] PRIMARY KEY ( [AccountID], [AddressID] ) WITH (FILLFACTOR=100, ONLINE=?, SORT_IN_TEMPDB=?);

    Why would this not be better served using a single PK Clustered Index, since the PK is already on both fields? Even if you only wanted to query results based on AccountID only, the single index would cover this.

    There is a 3rd index on just AccountID, which would be outside the scope of the clustered index.

    Any thoughts appreciated.

Viewing 0 posts

You must be logged in to reply to this topic. Login to reply