Going through the options: a) has no effect, since that's purely syntactic convenience: SQL Server translates that to PolicyDate >= '2/1/2001' AND PolicyDate <= '3/4/2002' anyway. b) A hash might work better, but it's clear that the index isn't being used, as you say. A hash join constructs a hash table of one side of the join, which the other looks up in, whereas a loop join simply loops over each side of the result set looking for matches. c) According to http://www.sql-server-performance.com/hints_table.asp[^], WITH(INDEX(0)) forces a table scan - precisely what we're trying to avoid. That same page recommends using index names rather than index IDs, because the IDs can change if the indexes are dropped and recreated - in other words, they're fragile. d) Updates any index statistics that are out of date. SQL Server uses the statistics to determine how good an index might be for finding the requested information. e) Rebuilding the index will incidentally update the statistics, but it's a lot of work that might not be necessary (and locks everyone out of the table while it does it). Assuming that appropriate indexes already exist (and I don't know which table contains which fields), then updating statistics might work. If there are no appropriate indexes, it won't help - at least one of the tables will have to be scanned to find the rows matching the WHERE clause, then those rows joined onto the other table. The problem description doesn't say whether the index scan was caused by the join operation or by the original lookup. Answering your question 3, I looked up 'hash join' in my copy of Inside SQL Server 2000 (which I thoroughly recommend). If there isn't a good index for the join (in this case, no index on AgentPolicy.PolicyNumber), a hash join might be cheaper. However, it can only be done for an equijoin (i.e. the join condition uses '=') and can take a lot of memory. The query optimiser won't use it if it thinks it will need to do more I/O to store and retrieve the temporary hash table than it will to repeatedly retrieve the original data. This is one reason to keep hints out of your queries - they tend to be very system specific. What helps one system might hurt another.