Question

We have a table value function that returns a list of people you may access, and we have a relation between a search and a person called search result.

What we want to do is that wan’t to select all people from the search and present them.

The query looks like this

SELECT qm.PersonID, p.FullName 
FROM QueryMembership qm
INNER JOIN dbo.GetPersonAccess(1) ON GetPersonAccess.PersonID = qm.PersonID
INNER JOIN Person p ON p.PersonID = qm.PersonID
WHERE qm.QueryID = 1234

There are only 25 rows with QueryID=1234 but there are almost 5 million rows total in the QueryMembership table. The person table has about 40K people in it.

QueryID is not a PK, but it is an index. The query plan tells me 97% of the total cost is spent doing “Key Lookup” witht the seek predicate.

QueryMembershipID = Scalar Operator (QueryMembership.QueryMembershipID as QM.QueryMembershipID)

Why is the PK in there when it’s not used in the query at all? and why is it taking so long time?

The number of people total 25, with the index, this should be a table scan for all the QueryMembership rows that have QueryID=1234 and then a JOIN on the 25 people that exists in the table value function. Which btw only have to be evaluated once and completes in less than 1 second.

Answer 1

if you want to avoid “key lookup”, use covered index

create index ix_QueryMembership_NameHere on QueryMembership (QueryID)
include (PersonID);

add more column names, that you gonna select in include arguments.

for the point that, why PK’s “key lookup” working so slow, try DBCC FREEPROCCACHE, ALTER INDEX ALL ON QueryMembership REBUILD, ALTER INDEX ALL ON QueryMembership REORGANIZE

This may help if your PK’s index is disabled, or cache keeps wrong plan.