I'm in the process of trying to optimize a query that looks up historical data. I'm using the query analyzer to lookup the Execution Plan and have found that the majority of my query cost is on something called a "Bookmark Lookup". I've never seen this node in an execution plan before and don't know what it means.
Is this a good thing or a bad thing in a query?
A bookmark lookup is the process of finding the actual data in the SQL table, based on an entry found in a non-clustered index.
When you search for a value in a non-clustered index, and your query needs more fields than are part of the index leaf node (all the index fields, plus any possible INCLUDE columns), then SQL Server needs to go retrieve the actual data page(s) - that's what's called a bookmark lookup.
In some cases, that's really the only way to go - only if your query would require just one more field (not a whole bunch of 'em), it might be a good idea to INCLUDE that field in the non-clustered index. In that case, the leaf-level node of the non-clustered index would contain all fields needed to satisfy your query (a "covering" index), and thus a bookmark lookup wouldn't be necessary anymore.
Marc
It's a
NESTED LOOP
which joins a non-clustered index with the table itself on a row pointer.Happens for the queries like this:
, if you have an index on
col2
.The index on
col2
contains pointers to the indexed rows.So, in order to retrieve the value of
col1
, the engine needs to scan the index oncol2
for the key values from1
to10
, and for each index leaf, refer to the table itself using the pointer contained in the leaf, to find out the value ofcol1
.This article points out that a
Bookmark Lookup
isSQL Server 2000
's term, which is replaced byNESTED LOOP
's between the index and the table inSQL Server 2005
and aboveFrom MSDN regarding Bookmark Lookups: