MySQL中无WHERE子句时SELECT COUNT(*)为何远慢于SELECT *？

问题场景 #

在MySQL 5.7环境中，对名为Lots的视图执行SELECT *仅需约0.2秒，但执行SELECT COUNT(*)却耗时25秒以上（结果为4136666条）。视图定义如下：

select
  lot.*,
  coalesce(overrides.streetNumber, address.streetNumber, lot.rawStreetNumber) as streetNumber,
  coalesce(overrides.street, address.street, lot.rawStreet) as street,
  coalesce(overrides.postalCode, address.postalCode, lot.rawPostalCode) as postalCode,
  coalesce(overrides.city, address.city, lot.rawCity) as city
from LotsData lot
left join Address address on address.lotNumber = lot.lotNumber
left join Override overrides on overrides.lotId = lot.lotNumber

性能差异的核心原因 #

• 执行计划逻辑完全不同
  MySQL对SELECT *和SELECT COUNT(*)的优化策略天差地别：SELECT *可以流式返回数据，优化器会优先选择能快速生成结果集的路径（比如利用底层表索引），甚至不需要完全生成所有数据就能开始返回；而COUNT(*)必须完整生成视图对应的全量结果集后，再逐行统计行数，无法提前终止或流式处理。

• LEFT JOIN与字段计算的额外开销
  视图包含两次LEFT JOIN和多个COALESCE函数：

  • LEFT JOIN可能导致结果集行数膨胀（如果Address/Override存在一对多关联），COUNT(*)需要处理所有膨胀后的行；
  • COALESCE的逐行非空判断逻辑，在SELECT *时是和数据返回并行执行的，但COUNT(*)完全不需要这些字段的值，却仍要执行所有计算，平白增加CPU开销。

• MySQL 5.7视图优化的局限性
  MySQL 5.7无法对视图的COUNT(*)请求做下推优化——也就是不能跳过视图逻辑，直接在底层LotsData表上执行COUNT(*)，必须严格执行视图的JOIN和字段计算逻辑后再统计，这就把原本可能毫秒级的计数变成了全量数据集的处理。

优化方案 #

1. 直接统计底层主表（前提是JOIN不增加行数）
   如果Address和Override表中每个lotNumber最多对应一条记录，视图结果集行数等于LotsData表行数，直接执行：

   SELECT COUNT(*) FROM LotsData;
   

   这个查询会利用LotsData的主键或索引快速返回结果，耗时会大幅降低。

2. 给JOIN字段添加索引
   为Address.lotNumber和Override.lotId添加单独索引，加速LEFT JOIN的匹配速度，减少视图结果集的生成时间：

   CREATE INDEX idx_address_lotnumber ON Address(lotNumber);
   CREATE INDEX idx_override_lotid ON Override(lotId);
   

3. 重写COUNT查询，绕开视图
   跳过视图直接编写COUNT逻辑，让MySQL优化器重新生成执行计划，可能会得到更优的路径：

   SELECT COUNT(*) 
   FROM LotsData lot
   LEFT JOIN Address address ON address.lotNumber = lot.lotNumber
   LEFT JOIN Override overrides ON overrides.lotId = lot.lotNumber;
   

   必要时可以添加STRAIGHT_JOIN提示强制指定表关联顺序。

4. 升级MySQL版本
   MySQL 8.0及以上版本在视图优化、COUNT下推方面有显著提升，优化器能智能识别这类场景，避免不必要的计算开销，从根源上解决这类性能问题。

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