500+ 万行表的主键列的选择查询没有响应

Question

I have a table in SQL Server having 500+ million rows with default clustered index defined on the primary key of table. I am running this simple query which takes more than 30 minutes.

Select count(ledgeridXXX) from Ledger.dbo.tblXXXX 

Here is the chunk of clustered index definition

CONSTRAINT [PK__tblDepar__AE70E0AFF9BAF7B9] PRIMARY KEY CLUSTERED 
(
    [LedgerIDXXX] ASC
) 
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
      ALLOW_PAGE_LOCKS = ON
) ON [PRIMARY]

I don't have any clue where it could be wrong and why is it taking so much time. Please suggest me some ways or techniques on how to fix it as this is a critical table and main reporting heavily relies on this table.

Answer 1

if you are just counting the number of rows, you can try this:

SELECT SUM(p.rows) as [cnt]
FROM sys.partitions AS p
INNER JOIN sys.tables AS t ON p.[object_id] = t.[object_id]
INNER JOIN sys.schemas AS s ON t.[schema_id] = s.[schema_id]
WHERE p.index_id = 1 /* clustered index */
AND t.name = N'tblXXXX'AND s.name = N'dbo';

the COUNT(clusteredkey) will probably have some overhead when you have intensive workload. this can take hours scanning the entire 500million rows.

if you are running higher version of SQL Server, you can use the columnstore index to speed up the COUNT .

References:

1. Bad habits - Count The Hard Way
2. Fast count - Stackoverflow
3. Columnstore Index Fast Count

Answer 2

What happens when you do COUNT(Column) , COUNT(1) , COUNT(*) without the where clause:

SQL Server finds the smallest (containing the least amount of columns, the most rows in a single AK page) index that will do the job.

If you only have a clustered index, this means it will use the clustered index. (The clustered index contains all columns of the table)

What you can do to speed things up:

1. Create a separate index with only 1 column, preferably a small data type. (The index creation can take lots of time).
2. Create an indexed view for your query. Since you aren't grouping I wouldn't recommend this.
3. Specify table hints WITH(TABLOCK) or WITH(TABLOCKX) to force a table lock or exclusive table lock.