I had same problem. The same query does massive logical reads on 2008 R2.

Stats on 2008.

Table 'Worktable'. Scan count 5, logical reads 5763460, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '******'. Scan count 1, logical reads 1295, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Stats on 2005

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '*******'. Scan count 1, logical reads 1306, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

When I compared the two execution plans. On 2008, it uses merge join and there is a sort. On 2005, it uses hash join.

So I forced hash join on 2008. sql then generated same query plan as 2005 and there was no sort no logical reads any more. My query was then 3 times faster.

Not sure why there is such a difference. I can confirm index fragmentation on tables involved was very low. I also even updated stats with full scan before enforcing hash join. 2008 still uses different query plan.

In a nutshell, in my case, I had to force a hash join to resolve the issue.