set persist比改my.cnf更可靠，因为它由mysql自动管理mysqld-auto.cnf（最后加载、优先级最高），避免人工误操作、覆盖冲突和多环境模板问题，支持运行中固化、重启不失效，且配置可查、可审计、可清理。
SET PERSIST 为什么比改 my.cnf 更可靠
因为 SET PERSIST 写入的是 MySQL 自己管理的配置文件 mysqld-auto.cnf，而不是人工编辑的 /etc/my.cnf 或 my.ini。它绕过了运维误操作、配置覆盖、多环境模板冲突等问题——比如你在线上用 Ansible 每次重写 my.cnf，但 SET PERSIST max_connections = 3000 的设置会稳稳保留在 mysqld-auto.cnf 里，重启后依然生效。
关键点在于：MySQL 启动时读配置的顺序是「系统级配置文件 → mysqld-auto.cnf（最后加载，优先级最高）」，所以哪怕你在 my.cnf 里写了 max_connections = 151，只要 mysqld-auto.cnf 里有 "max_connections": 3000，最终值就是 3000。
- 不需要重启 mysqld 就能持久化，避免服务中断
- 不依赖外部配置管理工具，DBA 可直接在 SQL 客户端完成
- 所有持久化变量统一存于
performance_schema.persisted_variables表，可查、可审计、可导出
RESET PERSIST 不等于恢复默认值，这点必须认清
执行 RESET PERSIST max_connections 后，max_connections 的值不会变回 151，也不会变成你上次 SET GLOBAL 的值，它只是把 mysqld-auto.cnf 里这一行删掉，然后下次启动时退回到「配置文件链」的下一个来源——也就是你 my.cnf 里写的值；如果没写，才用 MySQL 8.0 默认的 151。
常见踩坑场景：
- 误以为
RESET PERSIST是“撤销上一次 SET”，结果发现值没变，只是不再强制覆盖了 - 删了
mysqld-auto.cnf却没检查my.cnf是否留有旧值，导致重启后连接数突然掉回 151，应用大量报Too many connections - 在测试环境用
SET PERSIST调参后，忘了同步到生产my.cnf，上线后因文件缺失导致参数回退
为什么高并发调优必须用持久化变量
像 max_connections = 3000、innodb_buffer_pool_size = 40G 这类核心参数，一旦设错，轻则连接拒绝，重则内存耗尽触发 OOM Killer。而它们往往需要根据压测结果动态调整——这时靠改配置文件+重启，节奏太慢、风险太高。
SET PERSIST 提供了「运行中确认→立即固化→重启不失效」的闭环：
- 先
SET GLOBAL max_connections = 3000观察稳定性 - 稳定 24 小时后，再
SET PERSIST max_connections = 3000固化 - 无需等发布窗口，也不用协调运维停机
对比传统方式：vi my.cnf → systemctl restart mysqld → 等 3 分钟服务恢复 → 查监控是否异常，中间任何一步失败都可能引发雪崩。
容易被忽略的权限与兼容性细节
SET PERSIST 和 RESET PERSIST 都要求 SYSTEM_VARIABLES_ADMIN 权限，不是 root@localhost 就自动拥有——很多 DBA 在普通账号下执行直接报 ERROR 1227 (42501): Access denied，却以为是语法错了。
另外注意：
- MySQL 8.0.0+ 才支持，8.0.0～8.0.11 有若干 bug（如某些只读变量也能被持久化），建议至少用 8.0.12+
-
SET PERSIST对只读变量（如version）、会话级变量（如sort_buffer_size）无效，会报ERROR 1238 (HY000) - 若启用了
persisted_globals_load = OFF（例如故障排查时临时关闭），mysqld-auto.cnf将完全不被读取，此时SET PERSIST仍能写入文件，但重启后无效
真正麻烦的不是不会用，而是不知道它什么时候“看似生效、实则失效”——比如权限不够、变量不可持久化、或加载被禁用，这些都不会报 Warning，只默默跳过。
