Why surprising ? Is it the first optimizer gotcha with MySQL you ran into ?

Sure. This is a bit different though. You are adding whole another dimension tables for things which can’t be checked efficiently using index in original table (such as what day of the week it is) or which are not in the table (such as if it rained) – in this case you’ve got to add columns to fact table or dimension table as you did. That is a great thing to do.

My main point was a bit different one would be perfectly find to check range on date and group_id from the index on the table but MySQL Optimizer/Execution engine just not capable of doing so yet.

dt date
yy smallint # YEAR()
qq tinyint # QUARTER()
yyqq int #
mm tinyint #
dd tinyint
wknum1 tinyint # WEEK()
yywknum1 int # YEARWEEK()
wknum2 tinyint # some things define the first wk of the yr as the first wk with Sunday in that yr,
# so you sometimes end up with 2 definitions for what week of the year it is.
yywknum2 int # yy * 1000 + wknum2
dow tinyint # DAYOFWEEK()
dom tinyint # DAYOFMONTH()
doy tinyint # DAYOFYEAR()
yymmdd int
# flag fields
wkend tinyint # handy, but not necessary –
# makes queries more natural language
# select gross_rev from rev, days where rev.dt = days.dt and days.wkend = 1 and days.yy = 2008
# no where clause function calls, OMG!
fdom tinyint # first day of the month
ldom tinyint # last day of the month
fwdom tinyint # first work day of the month
lwdom tinyint # last work day of the month
fwdoy tinyint # first work day of the yr
lwdoy tinyint # last work day of the yr
usholiday tinyint # is this a US holiday?wh
rain tinyint # did it rain on this day?
snow tinyint # did it snow on this day?
over85 tinyint # was it over 85F on this day?
fire tinyint # were there wild fires in the area on this day?

I spin up records for as much of the past as needed and for the next 10 – 50 years.

This gives you the ability to quickly do reporting that includes very complex date requirements:
show me the coffee shop gross revenues for Q1 of the past 3 years for the first workday of each month during those periods.

For business that have business that changes substantially based on certain events, you can have flag fields for those. Screamin’ Mimi’s Ice Cream might want to have a report comparing Summer Saturday revenue on day hotter than 85F vs days cooler than that. Outdoor restaurants, boat rentals, downtown store that caters to the work day crowds, etc.

For other queries, having an easy way to check if something is the last day of the month is a blessing. It is massively useful and I can’t imagine design a system without it.

As you can see the trick is – if we have AND for different index part we can put selections on different tables instead and just use EQ join on the main fact table.

Why would you expect having ranges on different columns to help in this case ?

With optimizer we always find issues. Some of them are bugs others are just limitations in logic. In this case it is exactly this case – Optimizer could consider and use such plans but it does not do it, as it can’t do hash join, loose index scan etc.