为何简单索引查询会使Innodb_buffer_pool_read_requests增长400？

你的疑惑核心在于MySQL服务器层统计指标（Handler系列）与InnoDB引擎层统计指标（Innodb_buffer_pool_read_requests）的统计维度完全不同，以下是具体原因拆解：

1. 指标统计维度差异 #

• Handler_read_key = 1：这是MySQL服务器层的统计，仅记录用户查询通过索引定位到目标行的次数——你的查询通过ix_a索引找到1条匹配行，所以这个值是1，完全符合预期。
• Innodb_buffer_pool_read_requests = 400：这是InnoDB引擎层的统计，包含引擎内部所有逻辑读请求，不仅限于用户数据的读取，还包括引擎自身的元数据访问、事务处理、执行计划生成等操作，范围远大于Handler系列指标。

2. 核心原因：InnoDB内部的额外逻辑读 #

结合你的MySQL 8.0.40默认配置、Docker环境，导致400次逻辑读的关键因素有这些：

（1）数据字典的访问开销 #

MySQL 8.0将数据字典（表结构、索引元数据等）存储在InnoDB的系统表中。每次执行查询时，MySQL需要生成执行计划，必须读取这些系统表来获取表结构、索引信息，这些访问都会被计入Innodb_buffer_pool_read_requests。

（2）事务自动提交的额外操作 #

默认情况下MySQL是自动提交事务的，你的每一次查询都会触发：

• 事务的开启（生成MVCC快照）
• 事务的提交（更新事务状态、清理临时资源）
  这些操作需要InnoDB访问事务日志、undo log相关的页，带来额外的逻辑读请求。

（3）引擎内部的页操作开销 #

即使只读取一行数据，InnoDB也需要：

• 遍历二级索引ix_a的B树结构（从根节点到叶子节点，读取多个索引页的内部结构）
• 回表读取聚簇索引（主键索引）的页，访问页头、页目录来定位目标行
  每一次对页内结构的访问都会被算作一次逻辑读请求，累加后数量会远超用户可见的行读取次数。

验证建议 #

你可以尝试以下操作验证上述结论：

• 执行不需要回表的查询：SELECT a FROM my_table WHERE a=20000 LIMIT 1，此时不需要读取聚簇索引页，Innodb_buffer_pool_read_requests的增长会明显减少（但仍会有数据字典、事务相关的开销）。
• 多次执行同一查询后，观察Innodb_buffer_pool_read_requests的增长是否稳定：如果数据字典页已经被缓存到缓冲池，后续执行的增长应该保持稳定（和你现在看到的一致）。

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