我要评论前言
在日常的 mysql 运维中，你有没有遇到过这样的尴尬场景：
调优了一个关键参数，比如 innodb_buffer_pool_size，重启数据库后却发现配置又变回去了？
或者线上紧急修改了 max_connections，结果半夜服务器自动重启，连接数限制又打回原形？
如果你经历过这些，那恭喜你——你正站在 mysql8.0+带来的“参数持久化”新世界门口。
从 mysql8.0开始，官方引入了一项看似低调、实则革命性的功能：动态参数持久化（set persist）。它让数据库拥有了“记忆能力”——你改过的配置，即使重启也不会丢失。
今天，我们就来聊聊这个被很多人忽略、却能极大提升运维效率的功能，以及使用它时必须注意的几个坑。
一、以前的做法：靠手改配置文件
在 mysql8.0之前，动态修改参数只能通过set global临时生效。比如：
mysql> show global variables like 'max_connections';+-----------------+-------+| variable_name | value |+-----------------+-------+| max_connections | 1000 |+-----------------+-------+1 row in set (0.02 sec) mysql> set global max_connections =5000;query ok, 0 rows affected (0.00 sec) mysql> show global variables like 'max_connections';+-----------------+-------+| variable_name | value |+-----------------+-------+| max_connections | 5000 |+-----------------+-------+1 row in set (0.00 sec)
但一旦 mysql 服务重启，这个值就会恢复为 my.cnf 中的原始配置。
所以，dba们在线调整完动态参数后通常要进行如下的“双线操作”：
先用 set global 立即生效；
再手动编辑 my.cnf 文件，确保重启后不丢配置。
这不仅繁琐，还容易出错——比如忘记改配置文件，或者改错了路径、拼写错误，甚至在多实例环境下改混了配置。
更麻烦的是，在容器化、云原生时代，很多 mysql 实例根本没有持久化的配置文件挂载，每次重启都是“干净”的状态。这时候，传统方式几乎失效。
二、mysql8.0+的新解法：set persist
从mysql8.0版本开始引入了两个新语法：
set persist：修改参数并写入数据目录下的 mysqld-auto.cnf 文件，重启后依然有效。
set persist_only：只写入文件，不立即生效（适用于不能动态修改的参数）。
例如之前的修改连接数的操作就可以按照如下方式进行：
mysql> show global variables like 'max_connections';+-----------------+-------+| variable_name | value |+-----------------+-------+| max_connections | 1000 |+-----------------+-------+1 row in set (0.01 sec) mysql> set persist max_connections = 5000;query ok, 0 rows affected (0.02 sec) mysql> show global variables like 'max_connections';+-----------------+-------+| variable_name | value |+-----------------+-------+| max_connections | 5000 |+-----------------+-------+1 row in set (0.00 sec)
执行后，mysql 会自动在数据目录（如 /var/lib/mysql/）下生成或更新一个名为 mysqld-auto.cnf 的 json 格式文件的配置文件
内容如下：
{"version": 2, "mysql_dynamic_parse_early_variables": {"max_connections": {"value": "5000", "metadata": {"host": "localhost", "user": "root", "timestamp": 1769343323669674}}}}记录了修改的参数及修改后的值；另外也记录了哪个用户在哪台主机上于何时修改的参数，便于后期的审计
下次启动时，mysql 会先读取 my.cnf，再叠加 mysqld-auto.cnf 中的设置（后者优先级更高），从而实现“动态+持久”的统一。
三、这功能真香，但也有“雷区”
虽然参数持久化极大简化了运维，但如果不了解其机制，反而可能引发问题。
1. 雷区1：权限控制
只有拥有 system_variables_admin（mysql 8.0.12 之后）或 super 权限的用户才能使用 set persist。普通业务账号无法操作，这是安全设计，但也意味着你要提前规划好运维账号权限。
当然这个不算是雷区，本就应该有权限的用户才可以修改数据库参数。但也要控制好用户修改配置文件的权限。
2. 雷区2：配置优先级混乱
mysql 启动时的配置加载顺序是：
内置默认值
my.cnf（或 --defaults-file 指定的文件）
mysqld-auto.cnf（由 set persist 生成）
注意：第3步的优先级最高！
这意味着，即使你在my.cnf里写了 innodb_buffer_pool_size=2g，但如果之前用set persist设成了4g，那实际生效的还是4g。
这在团队协作中容易造成“配置漂移”——你以为改了配置文件就生效了，其实被auto.cnf覆盖了。
建议：定期检查mysqld-auto.cnf内容，或使用 reset persist 清理不再需要的持久化设置。
当然，直接删除mysqld-auto.cnf文件也可以达到清除持久化配置的效果。
3. 雷区3：不能持久化所有参数
并非所有参数都支持 persist。比如某些只读变量（如 version）、或必须在启动时确定的参数（如 datadir），就不能用 set persist 修改。
此时就需要使用set persist_only命令进行操作，此命令只持久化到配置文件，不修改当前内存值。主要用于只读变量（需要重启才能生效的参数）。
例如，对于只读变量innodb_log_file_size我们必须使用persist_only
mysql> show global variables like 'innodb_log_file_size';+----------------------+------------+| variable_name | value |+----------------------+------------+| innodb_log_file_size | 1073741824 |+----------------------+------------+1 row in set (0.00 sec) mysql> set global innodb_log_file_size=2*1073741824;error 1238 (hy000): variable 'innodb_log_file_size' is a read only variablemysql> set persist_only innodb_log_file_size=2*1073741824;query ok, 0 rows affected (0.01 sec) mysql> show global variables like 'innodb_log_file_size';+----------------------+------------+| variable_name | value |+----------------------+------------+| innodb_log_file_size | 1073741824 |+----------------------+------------+1 row in set (0.00 sec)
可以看出，修改后并没有立即生效。此参数需要重启后生效，例如：
mysql> restart;query ok, 0 rows affected (0.00 sec) mysql> restarting mysqld...2026-01-25t12:32:29.556858z mysqld_safe number of processes running now: 02026-01-25t12:32:29.571048z mysqld_safe mysqld restarted mysql> show global variables like 'innodb_log_file_size';error 2013 (hy000): lost connection to mysql server during queryno connection. trying to reconnect...connection id: 8current database: *** none *** +----------------------+------------+| variable_name | value |+----------------------+------------+| innodb_log_file_size | 2147483648 |+----------------------+------------+1 row in set (0.03 sec)
修改的参数也保存在 mysqld-auto.cnf配置文件中，可以看到标注的是静态参数mysql_static_variables列表中：
{"version": 3, "mysql_static_variables": {"innodb_log_file_size": {"value": "2147483648", "metadata": {"host": "localhost", "user": "root", "timestamp": 1769344313812486}}}}
四、 监控与审计
1. 参数配置查看
在mysql8.0版本之前想确定mysql是用哪个配置文件启动的这个问题，确定起来还是要费一点时间的，但是mysql8.0将每个参数的配置来源记录在了performance_schema.variables_info表中，且引入了set persist此特性后，可以查看每个命令是通过什么方式修改的。
mysql> select variable_name, variable_source, variable_path from performance_schema.variables_info limit 100;
2. 审计
利用performance_schema.variables_info表可以查看变量的来源、修改用户及时间等，便于追溯变量的修改
mysql> select * from performance_schema.variables_info where variable_source = 'persisted';+----------------------+-----------------+--------------------------------------------+-----------+----------------------+----------------------------+----------+-----------+| variable_name | variable_source | variable_path | min_value | max_value | set_time | set_user | set_host |+----------------------+-----------------+--------------------------------------------+-----------+----------------------+----------------------------+----------+-----------+| innodb_log_file_size | persisted | /data/mysql/mysql3307/data/mysqld-auto.cnf | 4194304 | 18446744073709551615 | 2026-01-25 07:31:53.812486 | root | localhost |+----------------------+-----------------+--------------------------------------------+-----------+----------------------+----------------------------+----------+-----------+1 row in set (0.00 sec)
五、结语：小功能，大价值
参数持久化看似只是一个语法糖，但它背后体现的是mysql向“自动化运维”迈出的关键一步。在 devops 和云原生盛行的今天，这种“运行时可配置 + 自动持久”的能力，正是现代数据库该有的样子。
下次当你再调整 mysql 参数时，不妨试试 set persist——但记得，用得好是利器，用不好就是隐患。毕竟，数据库不会说话，但它会记住你做的一切。
你们在生产环境里调整参数时，有没有遇到过奇怪的问题？比如调整后性能反而下降？
到此这篇关于mysql8.0数据库参数修改后重启不再失效的步骤及踩坑的文章就介绍到这了,更多相关mysql参数修改后重启不失效内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论