MySQL 的配置参数有几百个，大多数情况我们只需要关注其中十几项关键的即可。本节按照连接、缓冲池、日志、优化器四个维度，梳理生产环境中最值得关注的参数，给出明确的推荐值和理由。理解这些参数，你就能针对绝大多数业务场景完成基础的性能调优。
阅读提示：下文中的“建议值”适用于中等配置服务器（如 8 核 16G ~ 16 核 64G）上的通用 OLTP 业务。实际设置需根据服务器配置和业务特点微调。
21.1.1 连接参数
| 参数 | 说明 | 默认值 | 建议值 |
|------|------|--------|--------|
| max_connections | 最大客户端连接数 | 151 | 500~2000，视业务并发量而定 |
| max_connect_errors | 最大连接错误数，超限后主机被屏蔽 | 100 | 1000 或更高，避免误封 |
| connect_timeout | 连接握手超时时间（秒） | 10 | 10，通常无需改动 |
| wait_timeout | 非交互式连接空闲超时（秒） | 28800（8小时） | 300~600，及时释放空闲连接 |
| interactive_timeout | 交互式连接空闲超时 | 28800 | 同上，保持两者一致 |
重点解释
max_connections是数据库的“入口上限”。设置过小会直接拒绝新连接，设置过大则可能耗尽系统资源。一个粗略的估算公式：max_connections = (可用内存 - 全局缓冲池占用) / 单连接平均内存消耗。实际工作中，可以先用 500~800 观察，再结合监控工具（如 Grafana 中的Threads_connected）调整。另外，务必检查操作系统文件描述符上限（open_files_limit），它必须大于max_connections + table_open_cache。wait_timeout经常被忽略。默认 8 小时会导致大量空闲连接堆积，白白占用内存和连接数。很多应用使用连接池后，连接可能空闲较长时间，建议将该值降到 300 秒（5 分钟），同时确保连接池有心跳检测，避免连接被 MySQL 主动断开后应用报错。max_connect_errors如果设置太小（如默认 100），当某个应用因密码错误或网络闪断反复尝试时，主机可能被直接拉黑，排查起来很痛苦。线上建议调大到 1000 或更高，必要时手动执行FLUSH HOSTS清理。
21.1.2 缓冲池与内存参数
| 参数 | 说明 | 默认值 | 建议值 |
|------|------|--------|--------|
| innodb_buffer_pool_size | InnoDB 缓冲池大小，最重要的内存参数 | 128MB（5.7） / 128MB（8.0） | 物理内存的 50%~80% |
| innodb_buffer_pool_instances | 缓冲池分区数，减少并发竞争 | 8（当池>1GB时） | 4~16，建议等于 CPU 核数，但不超过 16 |
| innodb_log_buffer_size | Redo Log 内存缓冲区大小 | 16MB | 16MB~64MB，大事务可适当调大 |
| tmp_table_size / max_heap_table_size | 内部内存临时表最大尺寸 | 16MB | 16MB~64MB，根据业务临时表使用量调整 |
重点解释
innodb_buffer_pool_size是调优的第一要务。缓冲池直接缓存数据和索引页，命中率应达到 99% 以上。如果你的服务器专门用于 MySQL，可以设为物理内存的 70%~80%。比如一台 32GB 内存的服务器，可以设置 24GB。8.0 支持在线动态调整（SET GLOBAL），但重启后生效的配置仍需写入my.cnf。innodb_buffer_pool_instances默认值在 5.7 和 8.0 中都是8（当innodb_buffer_pool_size >= 1GB时）。它的作用是让多个实例并行处理内存页分配，减少锁竞争。一般设置为 4~8 即可，如果 CPU 核心数很多，可设为 8~16，但不要过多，每个实例至少应分配 1GB 以上才有意义。innodb_log_buffer_size可以加速小事务写入，但如果你的业务常有大事务（批量更新大量行），可以调大到 64MB~128MB，避免事务执行过程中频繁刷盘。注意，这只是缓冲区，最终还是要刷到 Redo Log 文件。
21.1.3 日志相关参数
| 参数 | 说明 | 默认值 | 建议值 |
|------|------|--------|--------|
| innodb_flush_log_at_trx_commit | 控制 Redo Log 刷盘策略 | 1 | 1（强一致） 或 2（高性能，允许丢一秒数据） |
| sync_binlog | 控制 Binlog 刷盘策略 | 1（5.7） / 1（8.0） | 1（强一致） 或 100~1000（高性能） |
| innodb_log_file_size | 单个 Redo Log 文件大小 | 48MB（5.7） / 48MB（8.0） | 512MB~2GB，需重启生效 |
| innodb_log_files_in_group | Redo Log 文件组数量 | 2 | 2~4，通常保持 2 即可 |
| binlog_format | Binlog 格式 | ROW（5.7.7+） / ROW（8.0） | ROW，生产环境强制 |
| expire_logs_days / binlog_expire_logs_seconds | Binlog 自动清理时间 | 30（8.0 改为秒设置） | 7~30 天，配合备份策略 |
重点解释
- 两个“1”参数决定数据持久性：
innodb_flush_log_at_trx_commit = 1：每次提交都刷 Redo Log 到磁盘，保证 ACID 中的 D。如果业务允许丢失最后一秒的数据（例如非金融类日志），可设为2，性能提升明显。sync_binlog = 1：每次提交都同步 Binlog 到磁盘，配合上面参数实现完整的持久化。同样，如果允许丢少量数据，可设为100或1000，减少磁盘 I/O。两者都设成高安全值时，写入性能会明显下降，建议在强需求下使用，同时配合 SSD 硬盘。innodb_log_file_size默认可怜的 48MB 几乎不适合任何生产负载。Redo Log 文件大小决定了系统可接受的写入峰值持续时间和崩溃恢复速度。建议设置为 512MB、1GB 或 2GB（5.7 和 8.0 都已支持 2GB）。调整此参数需要干净关闭 MySQL，移动旧文件，重启，请预留维护窗口。binlog_format一定要是ROW。STATEMENT格式存在主从不一致风险，MIXED不可靠，ROW格式是现代复制的基础，也是诸多工具（如 Canal、DTS）正常工作的前提。- Binlog 清理：8.0 中用
binlog_expire_logs_seconds取代了expire_logs_days（两者不共存）。建议保留最近 7 到 14 天的日志，确保有足够的恢复窗口，同时避免磁盘爆满。
21.1.4 优化器与查询参数
| 参数 | 说明 | 默认值 | 建议值 |
|------|------|--------|--------|
| optimizer_switch | 控制优化器一系列行为的开关集合 | 见官方文档 | 一般保持默认，谨慎调整 |
| eq_range_index_dive_limit | 等值范围比较时，统计估算的阈值 | 200（5.7.4+） / 200（8.0） | 200~1000，过大可能选错索引 |
| innodb_stats_persistent | 是否持久化 InnoDB 统计信息 | ON | ON，避免重启后统计信息丢失 |
| innodb_stats_auto_recalc | 是否自动重新计算统计信息 | ON | ON |
| sort_buffer_size | 排序缓冲区大小（按需分配，非全局占用） | 256KB（5.7） / 256KB（8.0） | 256KB~2MB，不要过大 |
| join_buffer_size | 关联缓冲区大小（用于无索引的关联） | 256KB | 256KB~2MB，同上 |
| read_buffer_size | 顺序读缓冲区 | 128KB | 128KB~1MB |
| read_rnd_buffer_size | 随机读缓冲区 | 256KB | 256KB~1MB |
重点解释
sort_buffer_size和join_buffer_size经常被误认为越大越好。实际上它们是按需分配的，一个 SQL 如果需要进行文件排序，就会分配一个这块内存，如果并发量大，内存占用会飙升。线上建议不超过 2MB，除非你明确知道该会话有巨大的排序需求（可以会话级调整）。eq_range_index_dive_limit是一个容易被忽略的细节。当IN列表中的值数量超过该阈值时，MySQL 不再逐个进行索引探查（index dive），而是直接使用统计信息估算。这会导致预估行数不准确，选错索引。如果你的 SQL 经常出现IN (200+)的情况，可以考虑适当调大此值（例如1000），但调太大会增加查询计划的生成开销。- 统计信息相关的参数建议保持开启，它们保证了在没有手动
ANALYZE TABLE的情况下，索引统计能够自动更新，帮助优化器做出正确决策。唯一需要注意的是，在大表上频繁增删改可能导致统计信息频繁更新，影响性能，但对于多数场景默认行为足够好了。
21.1.5 其他重要参数速查
| 参数 | 用途 | 建议 |
|------|------|------|
| innodb_flush_method | Redo Log 和数据文件的刷新方式 | Linux 下推荐 O_DIRECT，避免双缓存 |
| innodb_io_capacity | 后台刷新脏页的 I/O 能力 | SSD 设 2000~4000，机械盘 200~400 |
| innodb_io_capacity_max | 刷新能力的上限 | 设为 innodb_io_capacity 的两倍 |
| table_open_cache | 表缓存数量 | 建议 max_connections * 2 以上 |
| max_allowed_packet | 最大数据包大小 | 生产建议 16M~64M，避免大字段写入失败 |
| character_set_server | 服务器默认字符集 | utf8mb4，作为基础保障 |
| collation_server | 服务器默认排序规则 | utf8mb4_general_ci 或 utf8mb4_0900_ai_ci（8.0） |
| sql_mode | SQL 模式 | 建议包含 STRICT_TRANS_TABLES，8.0 默认已开启 |
重点说明
innodb_flush_method = O_DIRECT在 Linux 下非常重要，它能绕过操作系统页缓存，直接将数据写入磁盘，避免了 InnoDB 缓冲池和 OS 缓存的“双缓存”问题，提高效率。innodb_io_capacity直接影响后台刷盘的速度。在 SSD 上，默认的 200 会让清理过程过于保守，导致脏页累积，建议提高。你需要了解底层磁盘的 IOPS 能力，设置合理值。- 字符集一律推荐
utf8mb4。MySQL 中的utf8是阉割版，只支持最多 3 字节的字符，无法存储 emoji。从 8.0 开始，默认字符集已变为utf8mb4，但为了兼容性，新建库仍应显式指定。
21.1.6 配置检查清单
当你要上线或优化一个 MySQL 实例时，可以按下面顺序检查：
- 内存：
innodb_buffer_pool_size是否设成物理内存的 60%~80%？ - 持久性：
innodb_flush_log_at_trx_commit和sync_binlog是否满足业务对数据丢失的容忍度？ - 连接：
max_connections、wait_timeout是否匹配应用的连接池配置？ - 日志：
innodb_log_file_size是否< 512MB？binlog_format是不是 ROW？过期是否自动清理？ - 磁盘策略：
innodb_flush_method是否使用了O_DIRECT？innodb_io_capacity是否根据磁盘类型调整？ - 字符集：所有相关字符集变量是否统一为
utf8mb4？ - SQL 模式：是否开启了严格模式，避免脏数据？
- 缓存的合理大小：
sort_buffer_size、join_buffer_size等是否过大？
优化 MySQL 参数，不是一次配置完就万事大吉，而是在理解每个参数含义后，配合监控不断微调的过程。希望这份详解能成为你日常工作中的“调参速查手册”。