Question

I am having some performance issues with a query I am running in SQL Server 2008. I have the following query:

Query1:

 SELECT GroupID, COUNT(*) AS TotalRows FROM Table1 
    INNER JOIN (
        SELECT Column1 FROM Table2 WHERE GroupID = @GroupID
    ) AS Table2
     ON Table2.Column1 = Table1.Column1 
WHERE CONTAINS(Table1.*, @Word) GROUP BY GroupID

Table1 contains about 500,000 rows. Table2 contains about 50,000, but will eventually contain millions. Playing around with the query, I found that re-writing the query as follows will reduce the execution time of the query to under 1 second.

Query 2:

SELECT GroupID FROM Table1 
    INNER JOIN (
        SELECT Column1 FROM Table2 WHERE GroupID = @GroupID
    ) AS Table2 ON Table2.Column1 = Table1.Column1 
WHERE CONTAINS(Table1.*, @Word)

What I do not understand is it is a simple count query. If I execute the following query on Table 1, it returns in < 1 s:

Query 3:

SELECT Count(*) FROM Table1

This query returns around 500,000 as the result.

However, the Original query (Query 1) mentioned above only returns a count of 50,000 and takes 3s to execute even though simply removing the GROUP BY (Query 2) reduces the execution time to < 1s.

I do not believe this is an indexing issue as I already have indexes on the appropriate columns. Any help would be very appreciated.

Answer 1

Performing a simple COUNT(*) FROM table can do a much more efficient scan of the clustered index, since it doesn’t have to care about any filtering, joining, grouping, etc. The queries that include full-text search predicates and mysterious subqueries have to do a lot more work. The count is not the most expensive part there – I bet they’re still relatively slow if you leave the count out but leave the group by in, e.g.:

SELECT GroupID FROM Table1 
    INNER JOIN (
        SELECT Column1 FROM Table2 WHERE GroupID = @GroupID
    ) AS Table2 ON Table2.Column1 = Table1.Column1 
WHERE CONTAINS(Table1.*, @Word)
GROUP BY GroupID;

Looking at the provided actual execution plan in the free SQL Sentry Plan Explorer*, I see this:

And this:

Which lead me to believe you should:

1. Update the statistics on both Inventory and A001_Store_Inventory so that the optimizer can get a better rowcount estimate (which could lead to a better plan shape).
2. Ensure that Inventory.ItemNumber and A001_Store_Inventory.ItemNumber are the same data type to avoid an implicit conversion.

(*) disclaimer: I work for SQL Sentry.