根本原因是SET GLOBAL仅修改内存值，重启后从配置文件重新加载；而SET PERSIST将参数写入mysqld-auto.cnf，该文件启动时被自动加载但优先级低于my.cnf/my.ini，若两者冲突则配置文件生效。
MySQL服务重启后参数被重置，根本原因不是“没保存”，而是你改的压根没进**持久化配置源**——SET GLOBAL只写内存，SET PERSIST写的是mysqld-auto.cnf（非传统配置文件），而MySQL启动时优先加载的是my.cnf或my.ini。想真正锁定配置源，必须明确控制“谁说了算”。
确认当前生效的配置文件路径
别猜，让MySQL自己报路径：
- 运行
mysqld --verbose --help | grep -A 1 "Default options are read from"，输出顺序就是加载优先级：比如/etc/my.cnf→/etc/mysql/my.cnf→~/.my.cnf；后面读到的同名参数会覆盖前面的 - 如果MySQL正在运行，用
ps aux | grep mysqld查看进程参数，重点找--defaults-file=——这个路径就是它此刻认的唯一配置源 - Windows 下常见真实路径是
C:\ProgramData\MySQL\MySQL Server 8.0\my.ini（ProgramData默认隐藏，需开启显示）
区分 SET GLOBAL、SET PERSIST 和直接改配置文件的后果
三者写入位置和生命周期完全不同：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
SET GLOBAL var = value：仅存于内存，实例一重启就丢；不写任何文件，也不触发持久化机制 -
SET PERSIST var = value：写入mysqld-auto.cnf（默认在datadir下），该文件会被 MySQL 启动时自动加载，但优先级低于my.cnf—— 如果my.cnf里也定义了同一参数，它会被覆盖 - 直接编辑
my.cnf或my.ini：最可靠的方式，只要路径正确、格式无误、服务用它启动，参数就一定生效且重启不丢
锁定配置源的实操建议
目标是让修改只从一个地方加载，避免多源冲突：
- 删掉
mysqld-auto.cnf（如果不需要动态持久化场景），防止它和my.cnf冲突；执行SELECT * FROM performance_schema.persisted_variables;确认空结果 - 统一使用
my.cnf（Linux）或my.ini（Windows）作为唯一配置源，所有参数都放进去，放在加载顺序最靠后的那个路径下（例如 Linux 选/etc/my.cnf，Windows 选C:\ProgramData\...\my.ini） - 改完必须重启服务生效（
SET PERSIST不需要重启，但前提是你要的就是它那种“次优先级”的行为） - 检查语法：用
mysqld --validate-config验证配置文件是否可解析（MySQL 5.7.20+ / 8.0.14+ 支持）；错误常因缩进、分号、注释符号位置导致
真正容易被忽略的点是：即使你用了 SET PERSIST，只要 my.cnf 里有同名参数，它就永远赢不了——MySQL 的设计就是“配置文件 > 自动持久化文件 > 编译默认值”。想锁定，就得把配置文件变成唯一权威，其他来源要么清空，要么确保不重叠。
