1

I have a very simple query:

SELECT COUNT(*)
FROM messages
INNER JOIN users ON messages.user_id = users.user_id

With the join it takes 1146 ms and without it takes 220 ms (220 ms still seems slow to me). Test carried out on the messages table containing 1,000,000+ rows.

I have I have a primary key set on both tables (message_id and user_id) and a foreign key setup connecting messages.user_id and users.user_id.

The reason for this query is to provide the total number of records for a paging system.

What else can I do to speed up the query?

5
  • 2
    Do you have any rows in messages where user_id won't be in users? (e.g. is the foreign key nullable) Commented Aug 13, 2012 at 15:31
  • No there will always be a match
    – Darthtong
    Commented Aug 13, 2012 at 15:32
  • Please provide the CREATE TABLE statements including indexes and the execution plan. Commented Aug 13, 2012 at 15:34
  • 1
    I don't see the point of the join, unless you plan to add filtering on the users table (an index on messages.user_id should help then would ) By now, it seems that a simple select count(message_id) from messages should do the trick Commented Aug 13, 2012 at 15:46
  • Is the performance affected if you use a non-nullable column from messages in COUNT? I.e. SELECT COUNT(messages.message_id) FROM messages JOIN .... It should be possible for the optimizer to eliminate the join, check if that helps. Commented Jan 15, 2018 at 17:14

3 Answers 3

5

If the foreign key is not nullable, then there is no reason for the join at all, is there? So why not let SQL Server scan the most efficient index available instead of computing a join that will result in the exact same count?

SELECT COUNT(*) FROM dbo.messages;

That said, you can do this much more efficiently:

SELECT SUM(rows) FROM sys.partitions
  WHERE [object_id] = OBJECT_ID('dbo.messages')
  AND index_id IN (0,1);

This will be slightly inaccurate due to in-flight transactions, but it also won't block (or be blocked by) any activity against the table, so pick your poison.

3
  • 1
    If the FK is trusted and the column doesn't allow NULLs I would have thought SQL Server will optimise the join out. Commented Aug 13, 2012 at 15:36
  • 1
    @MartinSmith it may, I don't know that it's always guaranteed, but in any case the join code is still unnecessarily complex. The point of my answer was more about potentially trusting the catalog views to be "close enough" but orders of magnitude more efficient. Commented Aug 13, 2012 at 15:38
  • A worked example on SO of the performance difference of COUNT vs DMVs stackoverflow.com/a/6069288/27535
    – gbn
    Commented Aug 14, 2012 at 7:36
-1

You should create an index. An index can be created in a table to find data more quickly and efficiently.

The users cannot see the indexes, they are just used to speed up searches/queries.

CREATE INDEX index_name
ON table_name (column_name)

You should only create indexes on columns (and tables) that will be frequently searched against.

1
  • What index do you have in mind that will speed up the query in question? Commented Jan 15, 2018 at 17:06
-1

You're counting different things, from more data sources. Of course it's going to be slower.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.