MySQL查询优化：created_at范围count统计慢查询索引调优方案

你当前的慢查询问题核心是现有索引完全无法被该查询命中：
目前表上的复合索引是按category, token, reported_at顺序创建的，InnoDB的复合索引遵循最左前缀匹配规则，必须从索引最左列开始连续匹配才能生效。而你的查询过滤条件只有created_at >= '2019-03-01'，完全没用到复合索引的最左列category，因此这个索引在该查询里完全不起作用，数据库只能走全表扫描逐行判断条件，数据量上来之后效率会极低。

• 优先为查询条件字段创建适配的单列索引：直接执行CREATE INDEX idx_bugs_created_at ON bugs(created_at);给created_at字段建索引即可。因为你要的结果只是符合时间条件的总行数，走这个B+树索引的时候，数据库不需要回表查整行数据，直接遍历索引树的对应范围就能统计出总数，扫描量级会从全表行数降到符合时间条件的行数，性能提升非常明显。
• 不要随意修改现有复合索引结构：原有(category, token, reported_at)索引是服务其他按分类、令牌维度筛选，再按上报时间过滤/排序的业务场景，随便调整索引列顺序、或者往现有索引里加列，很可能导致原有业务的查询性能劣化。
• 单表数据量达到千万级以上、单索引还是无法满足性能要求时，可以额外考虑按created_at字段做Range范围分区，查询时数据库会自动裁剪掉2019-03-01之前的分区，进一步降低扫描的数据量。这个方案属于表结构层面的较大调整，建议数据量确实到瓶颈再用。

建完索引后可以执行EXPLAIN select count(*) from bugs where created_at >= '2019-03-01'看执行计划：如果key字段显示为你刚创建的idx_bugs_created_at、type字段值为range，就说明已经成功命中索引范围扫描，性能达到预期。

内容的提问来源于stack exchange，提问作者Bishoy Atef