MySQL8.0推出一个号称可以自适应服务器的参数，保证在各种不同的服务器、虚拟机、容器下自动适配服务器资源，让我们一起来看看到底它能自适应到什么地步。

在8.0中，innodb_dedicated_server默认是不开启的。

Command-Line Format	`--innodb-dedicated-server[={OFF\|ON}]`
System Variable	`innodb_dedicated_server`
Scope	Global
Dynamic	No
`SET_VAR` Hint Applies	No
Type	Boolean
Default Value	`OFF`

开启后，innodb可以自动配置下面的参数：它可以自动的调整下面这四个参数的值：

1. innodb_buffer_pool_size 总内存大小
2. innodb_log_file_size redo文件大小
3. innodb_log_files_in_group(as of MySQL 8.0.14) redo文件数量
4. innodb_flush_method 数据刷新方法

官方只是建议在可以使用全部的系统资源的专用服务器上配置开启该参数。比如用于mysql的docker容器或专用的虚拟机上开启。如果mysql和其它应用共享资源的话，是不建议开启该参数的。

只需将innodb_dedicated_server = ON 设置好，上面四个参数会自动调整，解决非专业人员安装数据库后默认初始化数据库参数默认值偏低的问题，让MySQL自适应的调整上面四个参数，本文以MySQL8.0.19为例。

那么按照什么规则调整呢？

MySQL官方给出了相关参数调整规则如下：

1. innodb_buffer_pool_size自动调整规则：

专用服务器内存大小	buffer_pool_size大小
小于1G	128MB （MySQL缺省值）
1G to 4G	OS内存*0.5
大于4G	OS内存*0.75

2. innodb_log_file_size自动调整规则：

buffer_pool_size大小	log_file_size 大小
小于8G	512MB
8G to 128G	1024MB
大于128G	2048MB

如果自适应导致innodb_log_file_size对应的redo log file超过了磁盘空间限制（这个空间得有多小！），将会采取以下措施：

新生成的日志文件redo log将被删除
错误日志显示如下
[ERROR] InnoDB: Error number 28 means ‘No space left on device’
[ERROR] InnoDB: Cannot set log file to size MB”

3. innodb_log_files_in_group自动调整规则：

（innodb_log_files_in_group值就是log file的数量）

buffer_pool_size大小	log file数量
小于8G	ROUND(buffer pool size)
8G to 128G	ROUND(buffer pool size * 0.75)
大于128G	64

说明：如果ROUND(buffer pool size)值小于2GB，那么innodb_log_files_in_group会强制设置为2。

4. innodb_flush_method自动调整规则：

该参数调整规则直接引用官方文档的解释：The flush method is set to O_DIRECT_NO_FSYNC when innodb_dedicated_server is enabled. If the O_DIRECT_NO_FSYNC setting is not available, the default innodb_flush_method setting is used.

如果系统允许设置为O_DIRECT_NO_FSYNC；如果系统不允许，则设置为InnoDB默认的Flush method。

InnoDB使用O_DIRECT刷新i/o，会略过操作系统的fsync()系统调用。

在mysql 8.0.14之前，该设置不适用于xfs、ext4文件系统，因为需要系统调用fsync()同步文件系统元数据。从8.0.14开始，创建一个新的文件后、增加文件大小后、或关闭文件后，就会调用fsync(),确保文件系统元数据被同步。但是没次写操作仍然会略过fsync()系统调用。

Data loss is possible if redo log files and data files reside on different storage devices, and a crash occurs before data file writes are flushed from a device cache that is not battery-backed. If you use or intend to use different storage devices for redo log files and data files, and your data files reside on a device with a cache that is not battery-backed, use O_DIRECT instead.

如果开启了自动配置的同时，显式配置上面的参数，在启动的时候会给出下面的提醒信息：

[Warning] [000000] InnoDB: Option innodb_dedicated_server is ignored for innodb_buffer_pool_size because innodb_buffer_pool_size=134217728 is specified explicitly.

一个选项的显式配置并不会阻止其他选项的自动配置。

如果开启了innodb_dedicated_server，同时显式配置了innodb_buffer_pool_size。innodb_log_file_size和innodb_log_files_in_group仍然根据buffer pool size的大小进行配置，但是这里的buffer pool size仍然是根据专用内存的大小估算的，哪怕实际配置给buffer pool的大小不是专用内存的大小。

每次重启后，mysql会根据需要自动重新配置变量的值。

目前它也只是探测了系统内存，实现起来比较简单，并且对性能改进非常有效，基本能解决绝大部分入门安装的性能问题。要解决其他问题，例如sort_buffer_size，read_rnd_buffer_size等连接内存自适应调整，需要对内存的精细控制，并且各种应用访问方式并不一样，并不是那么容易自适应；而innodb_read_io_threads，innodb_write_io_threads等需要根据CPU核数调整，也跟应用访问模式有一定关系；对于innodb_io_capacity而言，要探测底层存储设备具体的IO能力，并相应设置，也不是一个简单的工作。

适应场景

运行MySQL的服务器上是专门给MySQL提供服务的。innodb_dedicated_server的默认设置都是假设这个服务器的资源，MySQL都能用起来。
单机多实例情况下不适应。
其他有特殊场景要求的不适用。比如：不是主要以InnoDB为存储引擎的；服务器上还有其他应用程序的等等。

MySQL能“自适应”以尽量消耗更多的服务器资源。既避免了服务器扩展以后MySQLbuffer pool不变等，使用不了那么多资源；也避免了服务器缩减了以后MySQLbuffer pool过大等，导致MySQL服务进程启动不起来。这个参数的改变，意味着后续MySQL的类似参数会越来越优化，DBA排查问题时对MySQL参数的考虑会越来越少，MySQL的运维DBA的工作越来越简单了，MySQL也会越来越智能，DBA也快失业了；

总之，这个参数的新增，确实有点自适应的味道了，其他影响性能的自适应参数什么时候调，只能敬请期待了！！！