只有标记为dynamic且variable_scope='global'的参数才能真正热加载；如max_connections、wait_timeout、sql_mode及8.0.22+的innodb_buffer_pool_size，需先查performance_schema.variables_info确认is_dynamic='yes'和variable_scope='global'再执行set persist。
只有标记为 Dynamic 且 VARIABLE_SCOPE = 'GLOBAL' 的参数才能真正免重启生效；其他参数用 SET PERSIST 也只是“写进文件等重启”，不是热加载。
哪些变量能真正热加载？先查再改，别硬试
MySQL 不会主动告诉你某个变量能不能热改，硬写 SET PERSIST 报错才反应过来，已经晚了。必须提前查 performance_schema.variables_info 表确认两个条件同时成立：
IS_DYNAMIC = 'YES'VARIABLE_SCOPE = 'GLOBAL'
常见可热加载的变量包括：max_connections、wait_timeout、sql_mode、innodb_buffer_pool_size（MySQL 8.0.22+ 才支持动态调整该值）；典型不可热改的有：datadir、port、socket、server_id——这些改了 SET PERSIST 也会报 ERROR 1238 (HY000): Variable 'xxx' is a read only variable。
SET PERSIST 和 SET PERSIST_ONLY 的行为差异很实在
名字容易误导，关键看「是否立刻改内存」：
-
SET PERSIST max_connections = 5000;→ 内存立即变成 5000，同时写入mysqld-auto.cnf，下次启动还是 5000 -
SET PERSIST_ONLY log_bin = OFF;→ 当前 binlog 仍开着，只把"log_bin": "OFF"写进mysqld-auto.cnf，等重启才关闭
注意：SET PERSIST_ONLY 需要额外权限 PERSIST_RO_VARIABLES_ADMIN，普通 DBA 通常没有，执行时报 ERROR 1227 (42501) 基本就是这个原因。
执行失败不怪语法，大概率卡在权限、路径或加载开关上
报错信息往往不直说缺什么，得自己排查：
- 权限不足：报
ERROR 1227 (42000): Access denied; you need SYSTEM_VARIABLES_ADMIN privilege→ 普通root默认没这权限，得显式授权：GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'admin'@'%'; - 目录不可写：报
ERROR 3615 (HY000): Cannot write to mysqld-auto.cnf→ 容器挂载datadir为只读、SELinux 启用、或 MySQL 进程属主无写权限，都会导致失败 - 配置没加载：执行完
SET PERSIST，但重启后还是旧值 → 查SHOW VARIABLES LIKE 'persisted_globals_load';，如果返回OFF，说明mysqld-auto.cnf根本没被读取 - 被
my.cnf覆盖：即使mysqld-auto.cnf写成功了，若my.cnf中存在同名参数，它会覆盖前者（加载顺序：命令行 >mysqld-auto.cnf>my.cnf，但前提是mysqld-auto.cnf被加载）
真正容易被忽略的是：动态参数热加载 ≠ 所有参数都能热改，而 mysqld-auto.cnf 是自动管理的 JSON 文件，千万别手动编辑它；另外，像 innodb_buffer_pool_size 这类值，实际生效时可能按页对齐做舍入，看到和设置值略有出入是正常现象。
