作者Wayne LeutwylerPercona 技术客户经理原文https://percona.community/blog/2026/02/01/tuning-mysql-for-performance-the-variables-that-actually-matter/Feb 1, 2026爱可生开源社区翻译本文约 1900 字预计阅读需要 8 分钟。有一种只有 DBA 才能体会的无聊。就是盯着运行的服务器心想肯定有什么地方可以优化。好消息是确实有。本文将详细介绍几个能提升 MySQL 性能的变量解释它们的重要性以及调整这些变量何时能带来性能提升何时又会悄然降低性能。本文主要针对 InnoDB 存储引擎。1. innodb_buffer_pool_size1.1 真正值得关注的指标在修改这个变量之前请先查看以下内容SHOWGLOBALSTATUSLIKEInnodb_buffer_pool_read%;关键字段Innodb_buffer_pool_reads- 从磁盘的物理读取Innodb_buffer_pool_read_requests– 逻辑读取**经验法则**如果 reads/read_requests 1-2%则说明您的缓冲池太小。1.2 示例图表绘制Innodb_buffer_pool_reads随时间变化的曲线。健康的系统曲线应保持平稳或缓慢上升。出现类似城市天际线的峰值通常意味着内存压力过大或缓存冷却。如果说 MySQL 性能方面有一颗璀璨的明珠那非它莫属。1.3 它的作用InnoDB 缓冲池会将表数据和索引缓存到内存中。从内存读取数据速度很快。从磁盘读取数据……简直是磨练意志。1.4 如何调整它专用数据库服务器占用系统内存的 60%–75%共享服务器要节约内存为操作系统和其他服务预留内存SHOWVARIABLESLIKEinnodb_buffer_pool_size;1.5 特别提示如果你的数据库集群能够增加缓冲池MySQL 会给你带来神奇的体验。但如果放不下再多的查询优化也无济于事。2. innodb_buffer_pool_instances当内存容量增大时这一点就显得尤为重要。2.1 它的作用将缓冲区池拆分为多个实例以减少内部互斥锁争用。2.2 如何调整它仅当缓冲池大小 ≥ 1GB时才相关经验法则每 1-2GB 内存 1 个实例最多 8 个实例SHOWVARIABLESLIKEinnodb_buffer_pool_instances;2.3 特别提示并非越多越好。实例过多会浪费内存并可能降低性能。3. innodb_log_file_size3.1 真正值得关注的指标SHOWGLOBALSTATUSLIKEInnodb_log%;请注意Innodb_log_waitsInnodb_log_write_requests如果Innodb_log_waits不为零则 Redo Log 日志对于您的写入速率来说太小。3.2 示例图表绘制Innodb_log_waits每秒速率图。理想情况下这条线应该紧贴零点就像它害怕高度一样。该变量控制 MySQL 处理写入密集型工作负载的平稳程度。3.3 它的作用定义重做日志的大小。日志越大检查点就越少写入过程也越流畅。3.4 如何调校它OLTP 业务通常 Redo Log 总量为 1-4GB。大型交易受益于更大的日志SHOWVARIABLESLIKEinnodb_log_file_size;3.5 特别提示改变这一点需要重新开始。请做好相应计划否则将承受未来值班时的自己带来的怒火。4. innodb_flush_log_at_trx_commit4.1 真正值得关注的指标SHOWGLOBALSTATUSLIKEInnodb_os_log_fsyncs;从1切换到2通常可以大幅减少 fsync 次数。4.2 示例图表两条线重叠Transactions per secondInnodb_os_log_fsyncs per second对于繁忙的系统而言仅凭这张图表就足以让持怀疑态度的审计人员相信进行更改的合理性。性能与耐用性永恒的较量。4.3 它的作用控制 Redo Log 日志刷新到磁盘的频率。4.4 属性值1 – 最安全最慢每次提交都刷新2 – 非常受欢迎的折衷方案0 – 快速、高风险SHOWVARIABLESLIKEinnodb_flush_log_at_trx_commit;4.5 现实检验对于许多生产系统而言配置属性2可以在可接受的风险范围内带来巨大的性能提升尤其是在可靠的存储条件下。5. innodb_flush_method这个变量决定了 MySQL 如何与磁盘通信。5.1 它的作用控制 MySQL 是否使用操作系统缓存或绕过操作系统缓存。5.2 推荐的配置innodb_flush_methodO_DIRECT这样可以避免 MySQL 和操作系统页面缓存之间的双重缓冲。5.3 特别提示某些叫旧的文件系统和内核表现可能有所不同务必进行测试。6. max_connections这不是性能调节的旋钮而是控制耗损的旋钮。6.1 它的作用限制并发客户端连接数。6.2 为什么这很重要每个连接都会消耗内存连接过多会导致 MySQL 崩溃。SHOWVARIABLESLIKEmax_connections;6.3 特别提示设定得切合实际一些使用连接池监控Threads_connected7. thread_cache_size7.1 真正值得关注的指标SHOWGLOBALSTATUSLIKEThreads%;关键字段Threads_createdConnections如果Threads_created / Connections始终高于几个百分点则说明您的缓存容量不足。7.2 示例图表将线程数Threads_created作为计数器。一个健康的系统会呈现随时间推移而趋于平缓的曲线而不是阶梯状曲线。小改变大胜利。7.3 它的作用缓存线程这样 MySQL 就不会不断地创建和销毁线程。7.4 如何调整它SHOWSTATUSLIKEThreads_created;如果该数值持续上升则增加thread_cache_size。8. table_open_cache 和 table_definition_cache元数据比人们想象的更重要。8.1 它们的作用缓存打开的表和表结构以避免重复访问文件系统。Opened_tables值高元数据锁定等待SHOWVARIABLESLIKEtable_open_cache;SHOWVARIABLESLIKEtable_definition_cache;9. tmp_table_size 和 max_heap_table_size9.1 真正值得关注的指标SHOWGLOBALSTATUSLIKECreated_tmp%;观察Created_tmp_tablesCreated_tmp_disk_tables如果磁盘临时表超过总临时表的 5% 至 10%则查询会溢出到磁盘。9.2 示例图表堆积面积图内存临时表基于磁盘的临时表磁盘使用率缓慢上升通常表明存在伪装成 OLTP 的报表查询。基于磁盘的临时表是性能的隐形杀手。9.3 它们的作用限制内存临时表的大小。9.4 如何调整他们将两者设置为相同的值tmp_table_size256M max_heap_table_size256M9.5 特别提示这有助于解决复杂的查询问题但仍然需要修复错误的查询。10. slow_query_log 和 long_query_time这不是一项绩效指标而是一项绩效启示 。10.1 为什么这很重要你无法调整你看不见的东西。slow_query_logONlong_query_time1这使得猜测变成了证据。关于绘制这些指标图表的说明你不需要什么特殊的工具。这些工具就很好用performance_schemasysschema 视图Prometheus mysqld_exporterPercona Monitoring and Management (PMM)黄金法则永远绘制比率图表而不是原始计数。最后想说的话MySQL 的优化与其说是调整无穷无尽的参数不如说是了解压力点第一是内存第二是 I/O第三是并发性大多数性能提升都来自于少数几个变量而不是充满传奇色彩的复杂配置文件。如果今天只能调整一项那就调整缓冲池。如果只能调整两项那就添加 Redo Log。其他一切都是精益求精。如果你明天又觉得无聊恭喜你你正式成为一名数据库专家了。∎