MySQL能否优化GROUP BY外部的WHERE子句？如何理解查询优化器？

场景背景 #

我有三张表：

• users表和books表，都包含id（INT类型）、name（VARCHAR类型）等字段
• user_book_ratings表（类似Goodreads的评分系统），结构如下：

book_id: INT -- 关联书籍ID的外键
user_id: INT -- 关联用户ID的外键
rating: INT

要获取某特定书籍的评分统计（平均分、评分数量），直接查询的写法是：

select 
  book_id,
  avg(rating) as avgRating,
  count(rating) as numRatings
from user_book_ratings
where book_id = 123
group by book_id

因为book_id有索引，这个查询性能很好。

但因为需要做更复杂的聚合并关联其他查询，我想创建视图。但视图不能传参，存储过程又没法直接用于JOIN，所以我创建了一个全局聚合的视图：

create view rating_avgs as
select 
  book_id,
  avg(rating) as avgRating,
  count(rating) as numRatings
from user_book_ratings
group by book_id

然后通过外层查询过滤：

select *
from rating_avgs
where book_id = 123

我原本以为视图会先对所有书籍做聚合，再过滤book_id=123，但用EXPLAIN查看后发现，MySQL会用到book_id索引，处理的行数和直接在原查询加WHERE条件完全一样。这和我直觉不符，想知道我的理解哪里有问题，以及MySQL查询优化器的工作机制是怎样的？

解答 #

你的观察是准确的，MySQL的查询优化器会对视图和外层查询做合并优化——也就是把视图的定义和外层查询的条件整合到一起，生成等价的最优执行计划，而非先执行视图的全量聚合再过滤。

为什么会这样？ #

MySQL对于满足条件的简单视图（比如你这个仅按book_id分组聚合的视图）会执行「视图合并」操作：优化器会把外层查询的WHERE条件直接推送到视图的查询逻辑里，相当于把你的查询重写成了最初的直接聚合查询：

select 
  book_id,
  avg(rating) as avgRating,
  count(rating) as numRatings
from user_book_ratings
where book_id = 123
group by book_id

所以它能直接利用book_id的索引，只处理目标书籍的评分数据，效率和直接查询完全一致。

什么时候优化器不会做合并？ #

不是所有视图都会被合并，遇到以下情况时，优化器通常会先执行视图的完整逻辑，再处理外层查询：

• 视图中使用了DISTINCT、GROUP BY+HAVING、LIMIT、UNION/UNION ALL
• 视图包含嵌套子查询、复杂聚合逻辑
• 视图使用了STRAIGHT_JOIN或者受特定存储引擎限制

你的场景里，视图只是简单按book_id分组做基础聚合，没有上述复杂逻辑，所以优化器可以安全地将外层过滤条件下推，避免无意义的全表聚合。

验证优化器行为的方法 #

除了用EXPLAIN查看执行计划，还可以使用EXPLAIN ANALYZE（MySQL 8.0.18及以上版本支持）查看实际执行步骤，确认是否真的只扫描了目标book_id的索引范围。

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