从源码看穿！MySQL 优化器是如何估算 SQL 语句的访问行数的？

全文目录：

- 开篇语
- 📖 前言
- 🎯 目录
- 🚀 为什么估算访问行数这么重要？
- 🛠️ MySQL 优化器估算行数的原理概述
- 🔍 统计信息：优化器的基础数据
- 📈 行数估算的源码分析
- - 1️⃣ 获取统计信息
  - 2️⃣ 基于条件估算行数
  - 3️⃣ 索引选择
- 🏗️ 实战案例：行数估算如何影响 SQL 性能
- - 优化器的行数估算流程
- 🔄 延伸拓展：估算行数的挑战与改进思路
- 🎉 结语
- 文末

开篇语

哈喽，各位小伙伴们，你们好呀，我是喵手。运营社区：C站/掘金/腾讯云/阿里云/华为云/51CTO；欢迎大家常来逛逛

今天我要给大家分享一些自己日常学习到的一些知识点，并以文字的形式跟大家一起交流，互相学习，一个人虽可以走的更快，但一群人可以走的更远。

我是一名后端开发爱好者，工作日常接触到最多的就是Java语言啦，所以我都尽量抽业余时间把自己所学到所会的，通过文章的形式进行输出，希望以这种方式帮助到更多的初学者或者想入门的小伙伴们，同时也能对自己的技术进行沉淀，加以复盘，查缺补漏。

小伙伴们在批阅的过程中，如果觉得文章不错，欢迎点赞、收藏、关注哦。三连即是对作者我写作道路上最好的鼓励与支持！

📖 前言

Hello，数据库界的伙伴们！你有没有想过，MySQL 是怎么知道某条 SQL 语句大概会访问多少行数据的？这种能力不仅是个“炫技”的小把戏，实际上关系到查询优化器如何选择执行计划，是数据库性能优化的关键一环！本篇文章，我们将深入 MySQL 的源码，看看 MySQL 的优化器到底是如何估算 SQL 语句的访问行数的。放心，这篇文章会用通俗易懂的方式，带你理解这块“神秘领域”的核心原理和实现细节。

在文章中，我们将逐步揭开统计信息、索引选择、代价模型、行数估算等关键点的实现原理，同时提供实战示例。无论你是刚接触数据库优化的小白，还是想要精通 MySQL 的开发老手，都能从这篇文章中收获满满的干货！

🎯 目录

🚀 为什么估算访问行数这么重要？
🛠️ MySQL 优化器估算行数的原理概述
🔍 统计信息：优化器的基础数据
📈 行数估算的源码分析
🏗️ 实战案例：行数估算如何影响 SQL 性能
🔄 延伸拓展：估算行数的挑战与改进思路
🎉 结语

🚀 为什么估算访问行数这么重要？

在 SQL 查询优化中，估算访问行数是最关键的任务之一。优化器在生成执行计划时，会尝试找出访问代价最低的方案，这个代价不仅包含扫描行数，还包含各种操作的 CPU 和 I/O 成本。对于同一张表的不同查询条件，如果行数估算偏差大，优化器很可能选择了效率不佳的计划，导致查询耗时剧增。

设想以下几种场景：

条件扫描：假设我们查询一个庞大表中的少量数据。如果优化器高估了行数，可能会选择全表扫描；而如果低估了行数，又可能选择一个性能较差的索引。
多表连接：在多表连接查询中，估算行数不仅决定了连接顺序，还会影响最终的连接代价。
索引选择：MySQL 优化器会根据估算行数决定是否使用索引。如果误判了行数，可能会导致“不该用的索引被用上了”，反而影响查询性能。

因此，准确估算行数对于优化 SQL 执行性能至关重要！

🛠️ MySQL 优化器估算行数的原理概述

MySQL 优化器的行数估算，主要基于表的统计信息来完成。大致流程如下：

获取统计信息：优化器根据表的统计数据，如记录总数、索引分布、列的基数（distinct 值的数量）等，评估表的扫描代价。
基于条件的行数估算：对于带条件的 SQL 语句，优化器会结合统计信息估算符合条件的行数。例如，对于 WHERE age > 30 这种条件，优化器会参考 age 列的基数和分布情况，计算行数。
应用选择性公式：优化器使用选择性（selectivity）来估算行数。选择性是指一个条件过滤掉的数据比例，比如某个条件预计能筛掉 90% 的数据，那么选择性就是 10%。

这种基于统计信息的估算方法，可以避免全表扫描带来的时间开销，从而提高查询性能。

🔍 统计信息：优化器的基础数据

在行数估算中，统计信息是基础。MySQL 优化器会维护一系列统计信息，用于辅助行数估算。这些信息包括但不限于：

表的行数：表中总记录数，这是行数估算的起点。
列的基数（Cardinality）：即某列的唯一值个数。高基数表示列的值分布很广，低基数表示分布很窄。
索引选择性：用于评估某个索引是否合适。索引选择性越高，索引的过滤能力越强。
直方图（Histogram）：在一些数据库版本中，还会通过直方图记录列的分布信息，用于更精确地估算行数。

这些统计信息平时是自动更新的（例如 ANALYZE TABLE 命令会更新统计信息），优化器在查询过程中会实时使用这些统计信息。

📈 行数估算的源码分析

1️⃣ 获取统计信息

在源码中，MySQL 优化器会通过 TABLE_SHARE 结构体来获取表的基本信息。这其中包括表的行数（TABLE_SHARE::table_rows）和列基数（TABLE_SHARE::column_cardinality）。TABLE_SHARE 是一个保存表定义的结构体，优化器通过它获取统计信息。

longlong rows = share->table_rows;

2️⃣ 基于条件估算行数

接下来是条件的处理。在 SELECT_LEX::estimate_rowcount() 函数中，优化器会根据 WHERE 条件估算行数。这个过程首先根据条件中的列选择索引，再通过条件中的具体范围（如 >, <, BETWEEN 等）应用估算公式。

以 range_select() 函数为例：

double selectivity = ...; // 选择性估算
double estimated_rows = selectivity * rows;

这里，selectivity 通过条件筛选比例来计算，进一步估算出符合条件的行数。

3️⃣ 索引选择

choose_index() 函数会检查各索引的选择性，根据列的基数、索引的类型来判断。基数较高的列通常是优先选择的，因为它们能更好地筛选数据，降低扫描的行数。

if (index_cardinality > threshold) {
    use_index = true;
}

当满足选择条件时，优化器就会选择该索引，这也是优化器选择访问路径的关键步骤之一。

🏗️ 实战案例：行数估算如何影响 SQL 性能

假设我们有一张 employees 表，包含以下数据：

CREATE TABLE employees (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    age INT,
    department VARCHAR(20)
);

数据总量为 10 万条，且 age 列有较高的基数。我们执行以下查询语句：

SELECT * FROM employees WHERE age > 40;

优化器的行数估算流程

获取统计信息：假设 age 列的基数为 5000，表行数为 100000。
选择性估算：假设 age > 40 筛选条件选择性为 0.4，即约有 40% 的数据满足条件。
行数估算：优化器会估算 100000 * 0.4 = 40000 行数据会被访问。

基于该行数估算，优化器会判断是使用索引扫描还是全表扫描。在这个例子中，如果 age 列上有索引，优化器可能会选择索引扫描；若无索引，可能会选择全表扫描。

🔄 延伸拓展：估算行数的挑战与改进思路

行数估算看似简单，实则有不少挑战，尤其是在复杂查询中。以下是一些常见挑战及改进方向：

统计信息不准确：统计信息不可能时时刻刻准确无误，尤其是数据频繁变更的表。对于这类表，可以通过定期 ANALYZE TABLE 或引入动态采样来改进。
联合条件估算：多个条件同时存在时，选择性估算会变得复杂。MySQL 目前采用简单的条件叠加方法，但对于复杂条件，机器学习模型可能更精准。
使用直方图：MySQL 8.0 中引入了直方图，通过记录更详细的分布信息，能够提高条件筛选的精确度，进而优化行数估算。

未来，MySQL 优化器也在逐步引入更加智能化的模型，以进一步提升估算精度。