i’ve seen this happen
Especially if you’ve just inherited a database, or started using a vendor application. This can also be the result of inexperienced developers having free reign over index design.
Unless you’re running regular health checks on your indexes with something like our sp_BlitzIndex® tool, you might not catch immediately that you have a heap of HEAPs in your database.
You may be even further flummoxed upon finding that someone thoughtfully created Primary Keys with Nonclustered Indexes on them, yet no Clustered Indexes. Unless the original developer is still around, the intent may not be clear.
Using this code snippet, you can quickly identify tables that were created with Nonclustered Indexes on the Primary Key, and no Clustered Index. Another way to spot this potential issue might be looking for RID lookups, or Table Scans in your Plan Cache. Wide Nonclustered Indexes may also be present to compensate for the lack of a good Clustered Index.
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; SELECT QUOTENAME(SCHEMA_NAME([t].[schema_id])) + '.' + QUOTENAME([t].[name]) AS [Table] , QUOTENAME(OBJECT_NAME([kc].[object_id])) AS [IndexName] , CAST((SUM([a].[total_pages]) * 8 / 1024.0 ) AS DECIMAL(18,2))AS [IndexSizeMB] FROM [sys].[tables] [t] INNER JOIN [sys].[indexes] [i] ON [t].[object_id] = [i].[object_id] INNER JOIN [sys].[partitions] [p] ON [i].[object_id] = [p].[object_id] AND [i].[index_id] = [p].[index_id] INNER JOIN [sys].[allocation_units] [a] ON [a].[container_id] = CASE WHEN [a].[type] IN ( 1, 3 ) THEN [p].[hobt_id] WHEN [a].[type] = 2 THEN [p].[partition_id] END INNER JOIN [sys].[key_constraints] AS [kc] ON [t].[object_id] = [kc].[parent_object_id] WHERE ( [i].[name] IS NOT NULL AND OBJECTPROPERTY([kc].[object_id], 'CnstIsNonclustKey') = 1 --Unique Constraint or Primary Key can qualify AND OBJECTPROPERTY([t].[object_id], 'TableHasClustIndex') = 0 --Make sure there's no Clustered Index, this is a valid design choice AND OBJECTPROPERTY([t].[object_id], 'TableHasPrimaryKey') = 1 --Make sure it has a Primary Key and it's not just a Unique Constraint AND OBJECTPROPERTY([t].[object_id], 'IsUserTable') = 1 --Make sure it's a user table because whatever, why not? We've come this far ) GROUP BY [t].[schema_id] , [t].[name] , OBJECT_NAME([kc].[object_id]) ORDER BY SUM([a].[total_pages]) * 8 / 1024.0 DESC;
There are times when heaps are a valid choice
ETL or staging tables are the most common examples of when raw insert throughput is necessary, and a Clustered Index may not be.
But when tables are designed to be queried against and lack a Clustered Index, it’s usually a problem to be fixed.
Brent says: and remember, kids, SQL Server won’t suggest a clustered index.
Kendra says: if you think this probably didn’t happen to you, that’s a good sign you should doublecheck.