Normally, a group by implies that there will be a non-scalar result - hence the wording of "Evaluating Grouped" vs. "Evaluate Ungrouped"......whenever there is a "grouped" result, the optimizer likely chooses to use the forward index access method to do a sort-avert on the multiple rows *expected* for that result....whereas with the ungrouped it can try a backwards scan because it knows there will only ever be a single row result. It is interesting that in the second case you chose @MID in the select clause vs. MID....not sure if this makes a difference or not. Best thing to do on these queries is to not use showplan itself, but do something like:
set statement_cache off
set showplan on
set nodata on
set statistics plancost, resource, io, time on
set switch on 3604
go
-- query
go
set showplan off
set nodata off
set statistics plancost, resource, io, time off
set switch off 3604
go
IRT to your costing.....welllllllllllll...that ignores a lot of factors - e.g. when doing a range scan, we could do large IO's which isn't accounted for in your computation. Also we could do APF's - ditto.
But one of many influencers is data skew. For example, when evaluating your predicates, you only supplied MID. If assuming multiple (vector) output rows (vs. scalar) one factor that comes into pay is the relative uniqueness of the pair - which can depend on the stats for Date as well as the combination for MID+DATE.....it might be that other MID values have a lot less Date's and so the densities are skewed a bit to make the optimizer think a forward scan isn't so bad. To prove that, you would add:
set option show on
....to the above ...and post the output.