Please help me with the following questions as soon as possible…. 1) True or False, specifying a join hint will force join order? 2) When joining two small row sets together on an inner join, which join type is generally preferred? a. Hash Join b. Merge Join c. Loop Join 3) What is the difference between a hash join and a merge join? Thank you.
(comments are locked)
|
1) Join order will only be forced if you use the query hint that forces the order, FORCE ORDER. Then it will follow the order of the joins in the query. 2) There is always "it depends" to apply but generally the answer to this would be a loop join 3) First, a merge join requires that both inputs be sorted, so you'll frequently see extra sort operations ahead of a merge join when it's dealing with un-ordered data. A merge will take a row from each input and compare them, one a time. The merge is preferred on very large data sets where the data is pre-sorted. A hash join is usually between two sets of data where one is smaller than the other, similar to the loop. In this case the smaller input is built as a hash table, either in memory, or out to disk, with the key values being created as a hash. Then the other input is probed, a row at a time, comparing it's key, after hashing, to the hash table. There's more to it than that, but that's the basics. Usually a hash join works better on larger data sets, but where one is clearly smaller than the other. As with #2 above, "it depends" plays pretty heavily into which one works better in which situation. I have to add that anyone who hadn't read Grant's excellent book 'SQL Server Execution Plans' would struggle with these interview questions. Be prepared! Buy his book!
Dec 18, 2009 at 09:04 AM
Phil Factor
Thanks Phil. Appreciate the plug.
Dec 18, 2009 at 01:05 PM
Grant Fritchey ♦♦
(comments are locked)
|
Grant has you right on the money. If are hand tuning a lot of your queries you likely have other design issues. The execution plans are based on statistics and as the size of the subset change the plan might need to change also. Not only the overall design but look at the design of the querry itself. I have sped up a lot of queries by moving condidtions to the JOIN and taking them out of the where.
(comments are locked)
|
Why is this stuff urgent?
Because planning to do homework in advance is a hassle?
Or because they needed to fill out interview questions: http://www.sqlservercentral.com/Forums/Topic829341-1291-1.aspx