Questions about JOIN

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.

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.