SET PERSIST执行成功但重启失效，主因是mysqld-auto.cnf未被读取或被my.cnf同名配置覆盖；需确认persisted_globals_load=ON、变量可持久化、用户有SYSTEM_VARIABLES_ADMIN权限且数据目录下文件可读写。
MySQL 8.0+ 安装后直接用 SET PERSIST 报错或不生效，大概率不是语法写错了，而是权限、变量限制或文件权限没到位 —— 这些问题在初始化后的首次使用中特别容易踩坑。
为什么 SET PERSIST 执行成功但重启后失效
最常见原因是 mysqld-auto.cnf 文件没被读取，或者被覆盖/忽略。MySQL 启动时按顺序加载配置：先读 my.cnf（或 my.ini），最后才读 mysqld-auto.cnf；但如果 my.cnf 中显式设置了同名变量，它会覆盖 mysqld-auto.cnf 的值。
-
mysqld-auto.cnf必须位于 MySQL 数据目录下（可通过SELECT @@datadir;查看），且文件权限需允许 mysqld 进程读写（常见坑：SELinux 或宿主机挂载权限导致文件不可写） - 检查是否启用了
persisted_globals_load：若该变量为OFF，MySQL 根本不会加载mysqld-auto.cnf，执行SELECT @@persisted_globals_load;确认返回值是ON - 某些变量（如
innodb_log_file_size）是只读的，SET PERSIST会直接报错，必须改用SET PERSIST_ONLY
执行 SET PERSIST 前必须确认的三件事
缺一不可，否则命令看似成功，实际没写入文件或没生效。
- 当前用户需具备
SYSTEM_VARIABLES_ADMIN权限（仅靠root@localhost不自动拥有，需显式授权：GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'user'@'%';） - 目标变量必须是「可持久化」的全局变量 —— 查
performance_schema.persisted_variables表或参考官方文档中“Persistent System Variables”列表；像log_bin、hostname、audit_log_current_session这类明确标记为不可持久的变量，任何PERSIST操作都会失败 - 确保 MySQL 是以常规方式启动（非
--skip-grant-tables或--initialize-insecure模式），否则持久化机制被禁用
遇到 MY-011260 错误（ER_SYS_VAR_COMPONENT_FAILED_TO_MAKE_VARIABLE_PERSISTENT）怎么办
这个错误不是语法问题，而是底层组件拒绝写入 mysqld-auto.cnf，常见于 Docker 初始化后或权限受限环境。
- 检查 MySQL 数据目录（
@@datadir）下是否存在mysqld-auto.cnf，若不存在，手动创建并设权限：chown mysql:mysql /var/lib/mysql/mysqld-auto.cnf（Linux 宿主机上操作） - Docker 场景下，挂载的宿主机目录（如
/mydata/mysql）必须为空且属主为 UID 999（MySQL 容器默认用户），否则容器启动时跳过初始化，mysqld-auto.cnf不会被创建 - 如果已存在
mysqld-auto.cnf但内容为空或格式损坏（比如不是合法 JSON），MySQL 会静默忽略它；可用cat /var/lib/mysql/mysqld-auto.cnf | python3 -m json.tool验证合法性
验证持久化是否真正生效的快捷方式
别只信 SELECT @@max_connections —— 它只反映当前运行值。要确认是“持久化生效”，得绕过内存看落盘结果。
- 查表：
SELECT * FROM performance_schema.persisted_variables WHERE VARIABLE_NAME = 'max_connections';，有记录才说明已写入mysqld-auto.cnf - 手动查看文件：
cat /var/lib/mysql/mysqld-auto.cnf，确认 JSON 结构完整、Value字段是你设的值、Timestamp是最近时间 - 最硬核验证：停库 → 修改
my.cnf中同一变量为不同值 → 启动 → 查SELECT @@max_connections，若仍是你用SET PERSIST设的值，说明它确实覆盖了配置文件设置
真正麻烦的不是命令怎么写，而是 MySQL 启动时那一连串配置加载顺序、权限校验和文件状态检查 —— 它们全在后台静默发生，出问题时只给你一个模糊的“不生效”现象。盯住 @@datadir、persisted_globals_load 和 performance_schema.persisted_variables 这三个点，基本能定位 90% 的持久化失败原因。
