当前位置：首页 > news >正文

MySQL优化器统计信息配置指南

news 2025/9/28 10:47:20

这段内容出自 MySQL 官方文档，主题是 “配置非持久性优化器统计信息参数”（Non-Persistent Optimizer Statistics Parameters），属于 InnoDB 存储引擎的性能调优部分。下面我将逐段为你详细解释这段内容的含义，并用通俗易懂的语言帮助你理解其背后的原理和实际影响。

🌟 核心概念：什么是“优化器统计信息”？

在 MySQL 中，查询优化器（Query Optimizer） 负责决定执行 SQL 语句的最佳方式，比如是否使用某个索引、用哪个索引、是否进行全表扫描等。

为了做出这些决策，优化器需要知道一些关于表和索引的数据分布情况，例如：

一张表有多少行？
某个索引有多少不同的值？（即“基数”，Cardinality）
索引的选择性如何？

这些数据被称为 “优化器统计信息”（Optimizer Statistics）。

🔧 什么是“非持久性”统计信息？

MySQL 提供两种方式来存储这些统计信息：

类型	是否保存到磁盘	特点
持久性（Persistent）	✅ 是	统计信息写入磁盘，重启后不丢失
非持久性（Non-Persistent）	❌ 否	统计信息只存在内存中，重启后丢失

默认情况下，innodb_stats_persistent = ON，也就是启用持久性统计信息。

但如果你设置：

SET GLOBAL innodb_stats_persistent = OFF;

或者在创建/修改表时指定：

CREATE TABLE t (...) STATS_PERSISTENT=0;
ALTER TABLE t STATS_PERSISTENT=0;

那么这张表的统计信息就是 非持久性的 —— 只存在内存中，MySQL 重启后就会丢失，下次启动时需要重新采样生成。

🔁 非持久性统计信息何时更新？

当统计信息是非持久性时，它们会在以下几种情况下被自动更新（重新计算）：

1. 执行 `ANALYZE TABLE`

ANALYZE TABLE my_table;

这是最直接的方式，手动触发统计信息更新。

2. 查询元数据（如 `SHOW TABLE STATUS`, `SHOW INDEX`） + 开启了 `innodb_stats_on_metadata=ON`

默认这个选项是 OFF，但如果开启：

SET GLOBAL innodb_stats_on_metadata = ON;

那么每次执行：

SHOW TABLE STATUS
SHOW INDEX
查询 information_schema.TABLES 或 STATISTICS 表

都会导致 InnoDB 重新统计表的索引信息！

⚠️ 注意：这可能导致性能问题！

如果你的库有很多表或索引，这类操作会变慢。
执行计划可能不稳定（因为每次查元数据都可能改变统计值，进而改变执行计划）。

📌 所以建议：生产环境不要开启 innodb_stats_on_metadata。

3. 使用 `mysql` 客户端并启用 `--auto-rehash`（默认行为）

当你运行：

mysql -u user -p

默认启用了 --auto-rehash，它支持命令行自动补全数据库名、表名、列名。

但它的工作原理是：打开所有 InnoDB 表 → 触发统计信息更新！

🚀 后果：客户端启动变慢，尤其在大库上。

✅ 解决办法：关闭 auto-rehash

mysql --disable-auto-rehash -u user -p

4. 第一次打开一张表

当某张表第一次被访问（打开）时，InnoDB 会检查是否需要更新统计信息。

5. 表数据变化超过阈值（1/16 ≈ 6.25%）

如果自上次统计以来，表中有 超过 1/16 的数据被修改（插入、删除、更新），InnoDB 会认为统计信息过期，下次打开表时自动重新采样更新。

📌 这是一个启发式规则，防止执行计划基于过时的统计信息做出错误选择。

📊 如何控制统计信息的准确性？—— `innodb_stats_transient_sample_pages`

由于统计信息是通过采样得来的（称为 random dives：随机读取若干页），所以它的准确性取决于采样量。

参数说明：

参数名：innodb_stats_transient_sample_pages
作用范围：全局（GLOBAL）
适用场景：仅当 innodb_stats_persistent = OFF 时有效（非持久性统计）
默认值：8 页
可调范围：一般建议 8~100，太高会影响性能

工作原理：

InnoDB 从每个索引中随机抽取若干个数据页，分析其中的键值分布，估算出索引的“基数”（Cardinality）。

比如：

主键索引：每页都抽一点，估算总行数。
普通索引：看有多少不同值，判断选择性。

设置方法：

SET GLOBAL innodb_stats_transient_sample_pages = 20;

⚖️ 调整采样页数的影响

设置值	优点	缺点
太小（如 1~2）	快，I/O 少	统计极不准，可能导致优化器选错索引，引发全表扫描
适中（如 8~20）	平衡速度与精度	大表可能仍不够准
太大（如 100+）	更准确	每次更新统计信息都要读很多页 → 打开表变慢，`SHOW TABLE STATUS` 变卡

📌 特别提醒：

对 大表或频繁用于 JOIN 的表，8 页采样很可能不够！
不准确的统计 → 优化器误判索引有效性 → 导致 全表扫描（Full Table Scan） → 性能急剧下降。

相关建议参考官方文档：Avoiding Full Table Scans（避免全表扫描）

✅ 最佳实践建议

优先使用持久性统计信息
```
SET GLOBAL innodb_stats_persistent = ON; -- 默认已开启
```
这样统计信息保存在磁盘上，重启不失效，更稳定。
避免频繁触发统计更新
- 关闭 innodb_stats_on_metadata
```
SET GLOBAL innodb_stats_on_metadata = OFF;
```
- 客户端连接时加 --disable-auto-rehash，提升连接速度。
合理设置采样页数
- 如果你确实使用非持久性统计（如旧版本 MySQL），且有大量大表：
```
SET GLOBAL innodb_stats_transient_sample_pages = 32; -- 或 64
```
- 测试不同值对统计准确性和性能的影响，找到平衡点。
定期执行 ANALYZE TABLE
尤其是在大批量导入/删除数据之后，手动更新统计信息，确保执行计划最优。
不要临时调大 sample_pages → 执行 ANALYZE → 再调小
因为统计信息会在多种场景下自动更新（不只是 ANALYZE），这样做没有意义，反而增加复杂度。
根据表大小调整策略
- 小表：8 页足够
- 大表：建议提高采样页数（如 32~64）
- 混合型数据库：折中取值（如 20~32）

🧠 总结：一句话理解全文

当 MySQL 的 InnoDB 表使用非持久性统计信息时，统计结果只存在内存中，重启丢失；系统会在特定操作（如 ANALYZE TABLE、打开表、数据变更过多等）时自动重新采样；采样的准确度由 innodb_stats_transient_sample_pages 控制——太小不准，太大影响性能，应根据表的大小和业务需求权衡设置。