MySQL 8.0 持久化配置不生效的根本原因是 SET PERSIST 未真正落盘，需同时满足 persisted_globals_load=ON、datadir 目录可写、my.cnf 无同名变量覆盖，且用户具备 SYSTEM_VARIABLES_ADMIN 权限、变量支持动态全局修改。
MySQL 8.0 没有禁用持久化变量功能，它默认启用且强制开启——问题出在「你以为它该生效，但它其实没真落盘」。
真正卡住你的是权限、路径、配置加载顺序这三道关。下面直奔实操。
SET PERSIST 执行成功但重启失效，最常见原因
命令返回 Query OK 不代表写进了 mysqld-auto.cnf，更不代表 MySQL 启动时会读它。
-
persisted_globals_load必须为ON：这是开关总闸，不打开，mysqld-auto.cnf完全被忽略；查法：SELECT @@persisted_globals_load;；若为OFF，只能改my.cnf的[mysqld]段并重启 -
mysqld-auto.cnf所在目录（即SELECT @@datadir;返回路径）必须可写：Docker 中挂载目录属主不是mysql（UID 999），或 SELinux 限制，都会导致静默失败（错误日志里记ERROR 3615） -
my.cnf里有同名变量会覆盖mysqld-auto.cnf：启动加载顺序是「命令行 >mysqld-auto.cnf>my.cnf」，但注意——my.cnf是最先读的，最后生效的；实际优先级是「命令行参数 >my.cnf>mysqld-auto.cnf」，所以my.cnf显式写了max_connections=151，SET PERSIST写的2000就会被盖掉
执行 SET PERSIST 前必须确认的三件事
缺一不可，否则白操作。
- 用户要有
SYSTEM_VARIABLES_ADMIN权限：root@localhost 默认也不带这个权限，得显式授：GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'your_user'@'host'; - 目标变量必须支持持久化：查
performance_schema.variables_info，IS_DYNAMIC = 'YES'且VARIABLE_SCOPE = 'GLOBAL'；像datadir、port这类只读变量，SET PERSIST直接报ER_VAR_CANT_PERSIST - MySQL 不能以
--skip-grant-tables或--initialize-insecure方式启动：这两种模式下持久化机制被硬性禁用
如何验证是否真持久化成功？
别信 SHOW VARIABLES，它只告诉你当前内存值。要看两个地方：
- 查表：
SELECT * FROM performance_schema.persisted_variables WHERE VARIABLE_NAME = 'max_connections';—— 有记录才说明已落盘 - 查文件：进
SELECT @@datadir;目录，确认mysqld-auto.cnf存在且内容是合法 JSON（不要手动编辑！格式错会导致 mysqld 启动失败） - 终极验证：改完后重启 MySQL，再查
SELECT @@max_connections;，值不变才算真正成功
SET PERSIST 和 SET PERSIST_ONLY 的关键区别
一个改内存+落盘，一个只落盘。
-
SET PERSIST max_connections = 2000;：立刻生效，重启后还在 -
SET PERSIST_ONLY log_bin = OFF;：当前值不变（比如还是ON），只写进mysqld-auto.cnf，下次启动才生效；适合改log_bin、innodb_log_file_size这类不能热改的变量 - 两者都依赖
SYSTEM_VARIABLES_ADMIN；PERSIST_ONLY还额外需要PERSIST_RO_VARIABLES_ADMIN（只读变量持久化专用权限）
真正容易被忽略的点是：mysqld-auto.cnf 文件本身由 MySQL 自动管理，你手动能删，但不能手动改；权限、路径、配置加载顺序这三环只要漏一环，整个持久化链就断了——而错误往往不报在终端，只躺在错误日志里。
