其实也没那么夸张
从 lz 的 sql 来看, 会先用日期收敛结果, 所以实际对象只有 kw 级别

1. 如果查询场景(也就是 sql 的类型) 不多, 可以针对性的建索引优化
2. 但是由于怎么说都是聚合查询, 频率肯定不能过高, 否则 DB 机器的 CPU 会很高

实测:
1. 1.2亿记录的表
2. 125G 数据量

select zone_id, count(*) from log_2014_11 where id_1 = 32 group by id_2;
+---------+----------+
| id_2 | count(*) |
+---------+----------+
| 1 | 4983336 |
| 2 | 3628759 |
| 3 | 120960 |
+---------+----------+
3 rows in set (9.47 sec)

id_1, id_2 是一个联合次级索引的头两个字段, 速度不算很快, 但也不算很慢

环境
1. MySQL 5.5
2. Innodb
3. 32G 内存, SSD
4, 16G buffer pool