MySQL 8.4.0 LTS 变更解析：InnoDB 参数默认值变化

前情回顾

• MySQL 8.4.0 LTS 变更解析：源码编译（类库变更）和密码插件
• MySQL 8.4.0 LTS 变更解析：MySQL 的复制与组复制
• MySQL 8.4.0 LTS 变更解析：I_S 表、权限、关键字和客户端

MySQL 8.4.0 LTS 已经发布 ，作为发版模型变更后的第一个长期支持版本，注定要承担未来生产环境的重任，那么这个版本都有哪些新特性、变更，接下来少安将带大家一起来 get 新知识点。

MySQL 8.4.0 与 MySQL 8.0 相比有 23 个 InnoDB 系统变量的默认值发生了变化，具体变化一览如下表。

这里具体讲解其中几个系统变量。

1. innodb_buffer_pool_in_core_file

参数 innodb_buffer_pool_in_core_file 用于控制当MySQL服务器崩溃并生成core dump时，InnoDB缓冲池是否包含在core dump文件中。如果在core dump中包含缓冲池，这可能会使core文件非常大，从而使得调试和分析服务器崩溃的原因变得更加困难和耗时。因此，关闭这个参数可以减少core文件的大小，使得分析更为高效。

该参数之前的默认值是 ON，但在支持 MADV_DONTDUMP 的系统上，比如Linux 3.4及以上版本，它的默认值现在是 OFF。这意味着在这些系统上，InnoDB的缓冲池内容默认不会转储到core文件中。

在官方文档中，有描述该参数 ON/OFF 对 core dump file size 的影响。[1]

2. innodb_dedicated_server

参数 innodb_dedicated_server 允许 MySQL 实例在专用服务器上运行时，根据服务器可用的资源自动调整 InnoDB 的配置。如果 MySQL 实例与其他应用共享服务器资源，则不推荐开启该参数。启用 innodb_dedicated_server 后，MySQL 会根据服务器的内存大小自动设置 innodb_buffer_pool_size 和 innodb_redo_log_capacity 等参数，以优化数据库性能。

• innodb_buffer_pool_size

如果服务器内存小于 1GB， innodb_buffer_pool_size 将被设置为 128MB。
如果服务器内存在 1GB 至 4GB 之间， innodb_buffer_pool_size 将设置为服务器内存的 50%。
如果服务器内存超过 4GB， innodb_buffer_pool_size 将设置为服务器内存的 75%。

• innodb_redo_log_capacity

innodb_redo_log_capacity 将被设置为（可用逻辑处理器数量/2）GB，但最大不会超过16GB。

注意：

innodb_log_file_size 和 innodb_log_files_in_group 已弃用，并由 innodb_redo_log_capacity 取代。

3. temptable_max_ram

参数 temptable_max_ram 用于定义 TempTable 存储引擎在使用 InnoDB 磁盘上的内部临时表分配空间之前可以占用的最大RAM量。

在 MySQL 8.4 中， temptable_max_ram 的默认值根据系统内存的大小自动调整，将设置为系统内存的 3%，最小值为 1GB，最大值为 4GB。

以前的默认设置允许 TempTable 引擎使用内存映射文件，但在 MySQL 8.4 中， temptable_max_mmap 的新默认设置为 0 ，这意味着默认情况下禁止从内存映射临时文件分配内存。

MySQL 8.4 仅使用 InnoDB 存储引擎作为磁盘内部临时表， MyISAM 存储引擎不再用于该目的。

4. innodb_use_fdatasync

参数 innodb_use_fdatasync 默认值改为 OFF，之前是 ON。该参数在 MySQL 8.0.26 引入。

在支持 fdatasync() 系统调用的平台上（只支持 Linux 且需内核版本高于 2.2），启用 innodb_use_fdatasync 允许使用 fdatasync() 来代替 fsync() 系统调用来进行操作系统刷新。 除非后续数据检索需要，否则 fdatasync() 调用不会刷新文件元数据的更改，从而提供潜在的性能优势。

补充内容： TempTable 监控

可以通过查询 performance_schema 表来监控临时表占用空间的情况：

mysql> SELECT * FROM performance_schema.memory_summary_global_by_event_name
-> WHERE event_name like '%temptable%'\G
*************************** 1. row ***************************
EVENT_NAME: memory/temptable/physical_disk
COUNT_ALLOC: 0
COUNT_FREE: 0
SUM_NUMBER_OF_BYTES_ALLOC: 0
SUM_NUMBER_OF_BYTES_FREE: 0
LOW_COUNT_USED: 0
CURRENT_COUNT_USED: 0
HIGH_COUNT_USED: 0
LOW_NUMBER_OF_BYTES_USED: 0
CURRENT_NUMBER_OF_BYTES_USED: 0
HIGH_NUMBER_OF_BYTES_USED: 0
*************************** 2. row ***************************
EVENT_NAME: memory/temptable/physical_ram
COUNT_ALLOC: 2
COUNT_FREE: 1
SUM_NUMBER_OF_BYTES_ALLOC: 2097216
SUM_NUMBER_OF_BYTES_FREE: 1048608
LOW_COUNT_USED: 0
CURRENT_COUNT_USED: 1
HIGH_COUNT_USED: 1
LOW_NUMBER_OF_BYTES_USED: 0
CURRENT_NUMBER_OF_BYTES_USED: 1048608
HIGH_NUMBER_OF_BYTES_USED: 1048608
2 rows in set (0.00 sec)


往期精彩

• 从鸟山明到 MySQL 5.7 EOL
• 【MySQL 8.x】重磅！MySQL 8.1.0 已来！有彩蛋~
• 【MySQL 8.x】从参数变化解读 MySQL 8.2.0 发版说明
• 【MySQL 8.x】在 Rocky 9 上编译 MySQL 8.2.0 Debug 版本编译指南
• 【MySQL 8.x】定制化 MySQL 8.2.0 编译选项
• 【MySQL 8.x】MySQL Server 8.3.0 重要变更解析
• 如何选择适合的 MySQL Connector/J 版本
• MySQL 8.4.0 LTS 发布 (MySQL 第一个长期支持版本)
• MySQL 8.4.0 LTS 变更解析：源码编译（类库变更）和密码插件
• MySQL 8.4.0 LTS 变更解析：MySQL 的复制与组复制
• MySQL 8.4.0 LTS 变更解析：I_S 表、权限和客户端
• Oracle 数据库全面升级为 23ai
• python-oracledb 已率先支持 Oracle 23ai
• 一文带你了解 Oracle 23ai 新特性 Vector 的基础用法
• SOP for Oracle 23ai：Python 连接 Oracle 的两种方法

– END –

如果这篇文章为你带来了灵感或启发，就请帮忙点『赞』or『在看』or『转发』吧，感谢！(๑˃̵ᴗ˂̵)

1. https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool-in-core-file.html ↩︎