历史（问题是 2020 年以下）
2018。 之后新鲜的两年前安装 18.04 后，我想使用/etc/mysql/my.cnf16.04 中的设置来恢复原状。但 MySQL 安装设置了两个符号链接
/etc/mysql/my.cnf -> /etc/alternatives/my.cnf/etc/alternatives/my.cnf -> /etc/mysql/mysql.cnf
/etc/mysql/mysql.cnf因此我用旧的 16.04替换了新的/etc/mysql/my.cnf。
一切都很顺利，直到另一次 MySQL 更新，由于某些原因，我的mysql.cnf版本被替换为新的。有错误吗？我接受了替换吗？我想不会，但是，好吧，这总是有可能的。
所以我当时做的是绕过替代系统，即用/etc/mysql/my.cnf我的my.cnf文件替换链接，然后清零mysql.cnf。由于my.cnf优先于此，所以mysql.cnf有效（我想我尝试过符号链接mysql.cnf到我的my.cnf文件，还有其他麻烦，不记得了）。
（说实话，我不太喜欢我发现的替代实现，既繁琐又违反直觉）
2020。做了一个升级从 18.04 到 20.04。当然，MySQL 用替代链接重新创建了一个干净的环境。很好。
然而，为了完成升级，这次我想保持干净，尽可能
- 是否继续使用替代系统（取决于您的建议）
- 确保进一步的 MySQL 升级（除非是 v. 9）不会覆盖我的设置（或者它会询问）
保持 MySQL 安装干净的推荐方法是什么？
答案1
从 3 版本开始我就一直在使用 MySQL。某物我发现设置环境变量的最佳位置是在单独的.cnf文件中。使用现代版本的数据库（从 5.3 开始的所有版本），这些都可以写入目录/etc/mysql/mysql.conf.d/。这使我可以拥有如下目录结构：
drwxr-xr-x 2 root root 4096 Aug 6 23:08 ./
drwxr-xr-x 4 root root 4096 Aug 6 23:08 ../
-rw-r--r-- 1 root root 1434 Jun 27 2019 mysqld.cnf
-rw-r--r-- 1 root root 155 Jun 27 2019 z-application.cnf
-rw-r--r-- 1 root root 2893 Jun 27 2019 z-innodb.cnf
-rw-r--r-- 1 root root 1464 Jun 27 2019 z-replication.cnf
配置文件按字母顺序读取，这解释了丑陋的z-前缀，并且文件的用途非常不言自明：
| 文件 | 包含 |
|---|---|
application.cnf |
应用程序特定的设置，例如最大连接数、日志过期时间等。 |
innodb.cnf |
InnoDB 特定的设置，通常会随着时间的推移根据服务器所运行的硬件进行调整 |
replication.cnf |
复制特定的设置。 |
这使我拥有了一堆.cnf模板文件，其中预先填充了基本内容，可供新 MySQL 安装使用/定制。
关于这一做法背后的原因...
MySQL 会根据其安装平台以非常特殊的顺序读取配置文件。您可以使用以下命令向 MySQL 询问配置文件的名称和顺序：
mysqld --help --verbose
对我来说，这将输出 3,000 多行，但在顶部附近，你会看到以下内容：
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf
The following groups are read: mysqld server mysqld-8.0
对我来说，没有/etc/my.cnf文件。但是，有一个/etc/mysql/my.cnf文件。该文件中只有两行重要内容：
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
这样，MySQL 就会搜索.cnf中的所有文件/etc/mysql/conf.d/，然后搜索 中的所有文件/etc/mysql/mysql.conf.d/，并按字母顺序将它们读入引擎。我更喜欢加载变量后所有默认 MySQL 文件都会被读取，因为这样可以减少我的值被默认值覆盖的可能性。因此，因为/etc/mysql/mysql.conf.d/在 之后/etc/mysql/conf.d/，我的文件就会进入那里。
它们在更新期间从未被覆盖或修改。
希望这能给你带来一些探索。
答案2
（说实话，我不太喜欢我发现的替代实现方式，既繁琐又违反直觉）
替代系统并非特定于 MySQL；它是一个通用系统，在 Debian 和 Ubuntu 中用于各种软件包。我建议您了解它的工作原理以及如何与它集成。它旨在让用户完全控制 - 因此他们可以根据需要完全覆盖打包，或者如果他们想要打包提供的好处，则可以与它集成。
查看更新替代方案 (1) 手册页了解详情。
如果您有一个my.cnf无论如何都想使用的特定内容，那么您可以将其添加到某个地方，并将update-alternatives其设置为比包装提供的任何内容更高的优先级。然后它将集成并且永远不会被覆盖。
但是，如果您这样做，请理解，my.cnf将来升级 Ubuntu 时您的配置可能会失败，因为可用的配置指令会随着主要 MySQL 版本的发布而改变。您需要my.cnf随着 MySQL 的变化而保持自己的配置为最新。
如果您希望打包有所帮助，那么您可以按照 @Matigo 在其回答中建议的方式操作，并使用.d目录仅添加覆盖。在可行的情况下，我们会安排打包以自动调整配置，以避免在版本升级期间破坏 MySQL。但是，我们通常只对打包发货的文件执行此操作，而不会对您自己添加的文件执行此操作。
最终，虽然与打包配置默认值不同是完全合理的，但在 Ubuntu 版本之间升级时必须调整配置，因为 MySQL 对主要 MySQL 版本之间配置变化的期望。