在MySQL 8.4 LTS 版本中InnoDB哪些参数默认值发生变化？

阅读完本篇文章需要十分钟

📢 版本综述

MySQL 8.4 LTS 版本于美国时间 2024 年 4 月 30 日正式发布，是 MySQL 的第一个 LTS （Long Term Support）版本。它主要集中在功能淘汰、参数更新和 bug 修复等方面。

• 宣布弃用的参数已被正式移除
• 该版本中多个系统参数的默认值生了变更

🚀 新版生产环境默认参数

✴️ innodb_adaptive_hash_index

一直以来，AHI一直是造成一些性能问题的原因。每个有经验的 DBA 都会建议禁用它。

当数据未发生变化并完全缓存在缓冲池中时，AHI 可能会给select带来一些好处。一旦有写操作，或系统负载较高，或无法缓存读取所需的所有数据，自适应散列索引就会成为一个巨大的瓶颈。

为了获得更可预测的响应时间，建议禁用自适应散列索引。

✴️ innodb_buffer_pool_in_core_file

其实就是在支持MADV_DONTDUMP的系统上默认是关闭的，Linux 3.4开始支持MADV_DONTDUMP，所以该参数在当前很多发行版上默认是OFF。

较大的core files 会带来很多问题。使用这个参数前，建议了解相关联的参数`core_file。

✴️ innodb_buffer_pool_instances

👻 示例

在将 buffer pool 的大小设置为 2 GB（大于1GB） 之后，查看instances的数据量，我们发现其为2。

mysql> select @@innodb_buffer_pool_instances;
+--------------------------------+
| @@innodb_buffer_pool_instances |
+--------------------------------+
|                              2 |
+--------------------------------+

因为这时(innodb_buffer_pool_size / innodb_buffer_pool_chunk_size)/2为 8；而 MySQL 所在机器的逻辑 CPU 为8，所以innodb_buffer_pool_instances参数值默认为2，即8/4。

mysql> select @@innodb_buffer_pool_size/@@innodb_buffer_pool_chunk_size;
+-----------------------------------------------------------+
| @@innodb_buffer_pool_size/@@innodb_buffer_pool_chunk_size |
+-----------------------------------------------------------+
|                                                   16.0000 |
+-----------------------------------------------------------+
1 row in set (0.00 sec)

✴️ innodb_doublewrite_files

我们来看MySQL 8.0官方文档中该参数的默认值描述：

但感觉官方文档对这个参数的描述并不准确，按照个人经验，该参数和缓冲池的实例数量并没有关系。

👻 示例

比如在MySQL 8.0.32中innodb_buffer_pool_instances 为 8，如果按照官方文档的说法，应该有16个文件， 但是仅有两个double write buffer 文件。

mysql> select @@version;
+-----------+
| @@version |
+-----------+
| 8.0.32    |
+-----------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_instances;
+--------------------------------+
| @@innodb_buffer_pool_instances |
+--------------------------------+
|                              8 |
+--------------------------------+
1 row in set (0.00 sec)

mysql> 

-- files
-rw-r-----  1 mysql mysql    589824 May  2 07:51 '#ib_16384_0.dblwr'
-rw-r-----  1 mysql mysql   8978432 Apr 24 05:49 '#ib_16384_1.dblwr'

✴️ innodb_change_buffering

Change buffering是通过延迟对二级索引的写入操作来支持顺序 I/O 的技术。然而在最新的硬件上，随机 I/O 不再是问题，所以该参数默认值变更为none。

有效参数值：

-- none
-- inserts
-- deletes
-- changes
-- purges
-- all

✴️ innodb_doublewrite_pages

以前的innodb_write_io_threads默认值是4，所以没有显示设置该参数的话，innodb_doublewrite_pages 默认值为4。

出于性能考虑，通常给该参数会设置较大的值；所以这次默认值被修改到了128。

✴️ innodb_flush_method

需要注意的是，MySQL 如果部署在 Windows 上面的话该参数默认值为unbuffered。

一直以来，O_DIRECT 一直是首选值，一般建议设置为它来绕过文件系统缓存。但是还是建议根据实际测试情况选择。

比如在ext4下有些DBA会启用innodb_dedicated_server，使用危险值O_DIRECT_NO_FSYNC（但一般是经验老道的，知道潜在问题的同学）。

注意点： O_DIRECT设置是使用 O_DIRECT打开数据文件，使用 fsync() 来flush数据和日志文件。

✴️ innodb_io_capacity

这个参数默认值确实该修改了，因为现在企业基本都用读写性能好的RAIDs或者SSD，很少有传统磁盘了。

✴️ innodb_io_capacity_max

即在以前的版本中，如果2 * innodb_io_capacity没有达到2000，那么innodb_io_capacity_max默认值就是2000。

✴️ innodb_log_buffer_size

较大的 log buffer 可使大事务在运行时无需在事务提交前将日志写入磁盘，即减少磁盘IO。

✴️ innodb_numa_interleave

如果有一个NUMA Node就没什么用。

✴️ innodb_page_cleaners

The number of page cleaner threads that flush dirty pages from buffer pool instances. Page cleaner threads perform flush list and LRU flushing.

✴️ innodb_parallel_read_threads

即当logical processors / 8 小于4时，该参数默认值为4。

并行读取聚簇索引的功能，但是不适用于二级索引。

✴️ innodb_purge_threads

官方认为在一些较小的系统中，4 个 purge 线程可能会造成问题。针对这类系统，将默认值降至 1 是不错的选择。

✴️ innodb_read_io_threads

即当logical processors / 2 小于4时，该参数默认值为4。

✴️ innodb_use_fdatasync

在支持 fdatasync() 系统调用的平台上，启用 innodb_use_fdatasync 允许在操作系统刷新时使用 fdatasync() 而不是 fsync() 系统调用。除非后续数据检索需要，否则 fdatasync() 调用不会刷新对文件元数据的更改，从而提供潜在的性能优势。

✴️ temptable_max_ram

定义 TempTable 引擎在利用磁盘存储数据前可使用的最大内存。默认值为服务器可用内存总量的 3%，最小和最大默认值范围为 1-4 GB。

✴️ temptable_max_mmap

✴️ temptable_use_mmap

定义当 TempTable 引擎占用的内存量超过 temptable_max_ram 限制时，TempTable 引擎是否为内部内存临时表分配内存映射临时文件的空间。默认情况下 TempTable  引擎会使用 InnoDB 磁盘上的内部临时表。