技术译文 | MySQL 社区经理:MySQL 8.4 InnoDB 参数默认值为什么要这么改?

目前,MySQL 的发布模型分为两个主要路径:LTS 版(长期支持)和创新版。所有 LTS 和创新版本都包含错误和安全修复,并被视为生产级质量。更多 MySQL 版本介绍[1] 


技术译文 | MySQL 社区经理:MySQL 8.4 InnoDB 参数默认值为什么要这么改?-1


MySQL 发布模型(图片来源:oracle.com)

什么情况适合 LTS 版?

  • 需要稳定的功能和更长的支持期。

  • 除了第一个 LTS 版本删除了一些功能,其他版本仅包含必要的修复,不在删除功能。

  • LTS 版本遵循 Oracle 终身支持政策(5 年主要支持和 3 年延长支持)。

什么情况适合创新版?

  • 想了解最新功能、改进。适合快节奏开发环境中的开发和 DBA,具有更高水平的自动化测试和现代持续集成技术,可实现更快的升级周期。

  • 除新功能外,随着代码重构、删除不推荐功能以及修改 MySQL 使其更符合 SQL 标准(在 LTS 版本中不会发生)。

  • 支持至下一个创新版。

更多了解:《一文了解 MySQL 全新版本模型》

MySQL 各版本的生命周期

技术译文 | MySQL 社区经理:MySQL 8.4 InnoDB 参数默认值为什么要这么改?-2

以下内容为 MySQL 社区经理 Frederic Descamps 对该版本中 InnoDB 参数默认值修改的详细介绍。

发布于 2024 年 5 月 1 日


技术译文 | MySQL 社区经理:MySQL 8.4 InnoDB 参数默认值为什么要这么改?-3

昨天(4 月 30 日),MySQL 的第一个 LTS 版本 MySQL 8.4[2] 发布了。

许多弃用的内容最终被删除,并且几个 InnoDB 变量默认值已被修改以匹配当前的工作负载和硬件规格。

有 20 个 InnoDB 变量的默认值已被修改!

让我们看一下这些变量并解释这样修改的原因:

1被修改默认值的 InnoDB 变量

innodb_buffer_pool_in_core_file

版本 默认值
8.4 之前 ON
8.4 LTS 如果支持 MADV_DONTDUMP 为 OFF,否则 ON

MADV_DONTDUMP 是 Linux 3.4 及更高版本中支持的宏指令(存在“ sys/mman.h”头文件并包含符号 MADV_DONTDUMP,一个 madvise()
 的 non-POSIX 扩展),Windows 系统或大多数 MacOS 系统不支持此宏。

总之,这意味着默认情况下,在 Linux 系统上,缓冲池的内容不会转储到核心文件中。

innodb_buffer_pool_instances

版本 默认值
8.4 之前 8(如果 BP < 1 GB,则为 1)
8.4 LTS 如果 BP 1 GB:则为 1-64 范围内的最小值:
a. (innodb_buffer_pool_size innodb_buffer_pool_chunk_size) 2
b. 1/4 可用逻辑处理器

旧值 8 在某些系统上可能太大。手册中包含 BP 大小计算的好示例,请参阅 配置 InnoDB 缓冲池大小[3]。

innodb_change_buffering

版本 默认值
8.4 之前 all
8.4 LTS none

Change Buffer 是一种通过延迟对二级索引的写入操作来支持顺序 I/O 的技术。在最新的硬件上,随机 I/O 不再是问题。

innodb_dedicated_server

版本 默认值
8.4 之前 OFF
8.4 LTS OFF

从 MySQL 8.0 开始,当 MySQL 运行在可供数据库使用的所有资源的专用服务器上时,我们建议启用此变量,并且不要手动修改 InnoDB 设置。

该变量的默认值是相同的,但是通过启用 innodb_dedicated_server
控制的变量是不同的。

  • innodb_buffer_pool_size
    • 128MB 是服务器内存小于 1GB。
    • 如果服务器内存在 1GB 到 4GB 之间,则检测到的服务器内存 * 0.5。
    • 如果服务器内存超过 4GB,则检测到的服务器内存 * 0.75。
  • innodb_redo_log_capacity:(可用逻辑处理器数量/2)GB,最大 16GB。

innodb_dedicated_server
启用时,innodb_flush_method
不会自动配置。

innodb_adaptive_hash_index

版本 默认值
8.4 之前 ON
8.4 LTS OFF

AHI(InnoDB 自适应哈希索引)长期以来一直是一些性能问题的原因。每个经验丰富的 DBA 总是建议禁用它,就像旧的查询缓存一样。我很惊讶没有像 Domas Mituzas 的查询缓存调优器那样的 AHI 调优器 😉

当没有数据发生更改并且完全缓存在缓冲池中时,AHI 可能会对读查询 (SELECT) 提供一些好处。一旦有写入操作,或者系统负载较高,或者读取所需的所有数据都无法缓存,自适应哈希索引就会成为巨大的瓶颈。

为了获得更可预测的响应时间,建议禁用它。

innodb_doublewrite_files

版本 默认值
8.4 之前 innodb_buffer_pool_instances * 2
8.4 LTS 2

之前默认值是根据缓冲池的数量计算的,为了简化,现在默认为 2。

相关文档[4] 指出该值定义每个缓冲池的双写文件数。但我的印象是,它是全局的,与缓冲池实例的数量无关。

从 MySQL 错误日志来看:

2024-05-01T05:43:03.226604Z 1 [Note] [MY-012955] [InnoDB] Initializing buffer pool, total size = 2.000000G, instances = 2, chunk size =128.000000M <br>[...]<br>2024-05-01T05:43:03.288068Z 1 [Note] [MY-013532] [InnoDB] Using './#ib_16384_0.dblwr' for doublewrite<br>2024-05-01T05:43:03.295917Z 1 [Note] [MY-013532] [InnoDB] Using './#ib_16384_1.dblwr' for doublewrite<br>2024-05-01T05:43:03.317319Z 1 [Note] [MY-013532] [InnoDB] Using './#ib_16384_0.bdblwr' for doublewrite<br>2024-05-01T05:43:03.317398Z 1 [Note] [MY-013566] [InnoDB] Double write buffer files: 2<br>2024-05-01T05:43:03.317410Z 1 [Note] [MY-013565] [InnoDB] Double write buffer pages per instance: 128<br>2024-05-01T05:43:03.317423Z 1 [Note] [MY-013532] [InnoDB] Using './#ib_16384_0.dblwr' for doublewrite<br>2024-05-01T05:43:03.317436Z 1 [Note] [MY-013532] [InnoDB] Using './#ib_16384_1.dblwr' for doublewrite<br>

有些现在可以自动调整以更好地匹配 MySQL 运行的系统。

享受 MySQL 并享受新的默认设置!