The table in question was a rollup/aggregation table.
Then it is not only fine, it is "right".
And it smells like a Summary table, since it begins with
Do you have some secondary indexes? Keep in mind that if you are using InnoDB, the rest of the PRIMARY KEY columns will be tacked onto the end of the secondary index. Again, this is not necessarily a problem.
100M rows is a lot for a rollup. It sounds like the table is too fine-grained. That is, perhaps instead if (date,a,b,c,d) you should have 4 rollups with PKs like (date,a,b,c), (date,b,c,d), (date,c,d,a), (date,d,a,b) (or some suitable combinations). I doing that, each might be only 10M rows, thereby making reports still faster, while having nearly as much flexibility in report.
Or maybe switch to (week,a,b,c,d), leading to maybe only 14M rows. (Probably more.)
Using PARTITION to facilitate pruning --- High speed ingestion --- Data Warehouse tips --- Summary Tables. These summarize many of the techniques I have developed in several DW projects. As you may infer, each project is different. The 'typical' number of Summary Tables (in my experience) is 3-7. The target in summarization is 10 Fact rows --> 1 Summary row. (That may be a 'median'.) In a rare case, I summarized a Summary table. In another rare case, I PARTITIONed a Summary table to good effect; usually Summary tables are small enough so they are fast enough for direct access from a UI.