mysql 8.0 中仅标记为 dynamic 且 variable_scope='global' 的参数（如 innodb_buffer_pool_size、max_connections、wait_timeout、sql_mode）支持真正热加载；set persist 虽将配置写入 mysqld-auto.cnf 并重启生效，但受限于权限、变量类型、取值范围及 my.cnf 同名参数覆盖等前提，并非绝对永久生效。
MySQL 8.0 支持真正的配置热加载，但仅限于动态参数；静态参数不能实时生效，必须用 SET PERSIST_ONLY 配合重启，且需对应权限。
哪些参数能真正热加载？
只有标记为 Dynamic 的系统变量才能通过 SET GLOBAL 或 SET PERSIST 实时生效。比如：
-
innodb_buffer_pool_size：可动态调整（需满足页对齐，实际生效值可能略作舍入） -
max_connections、wait_timeout、sort_buffer_size：改完立刻影响新连接 -
sql_mode：动态修改后，后续会话立即按新规则解析 SQL
查一个变量是否动态，执行：SELECT VARIABLE_NAME, VARIABLE_SCOPE FROM performance_schema.variables_info WHERE VARIABLE_NAME = 'innodb_buffer_pool_size';。若 VARIABLE_SCOPE 是 GLOBAL，说明支持动态设置。
为什么 SET PERSIST 不等于“永久生效”？
SET PERSIST 把参数写入数据目录下的 mysqld-auto.cnf（JSON 格式），下次启动时自动加载 —— 但它只对动态参数有效，且有前提：
- 必须有
SYSTEM_VARIABLES_ADMIN权限 - 写入的值必须符合变量类型和取值范围，否则报错
ER_INVALID_VALUE_FOR_VAR - 如果该参数在
my.cnf中已被显式配置，mysqld-auto.cnf的值会被忽略（文件加载顺序：硬编码 my.cnf mysqld-auto.cnf）
示例：SET PERSIST innodb_buffer_pool_size = 4294967296; 成功后，mysqld-auto.cnf 里会新增字段；但若你在 my.cnf 里写了同名参数，重启后仍以 my.cnf 为准。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
SET PERSIST_ONLY 的真实用途和陷阱
SET PERSIST_ONLY 是给静态参数“打补丁”的唯一方式，比如 server_id、binlog_format、datadir —— 它们无法动态修改，但你可以用它把值存进 mysqld-auto.cnf，等下次重启时加载。不过要注意：
- 执行前必须拥有
PERSIST_RO_VARIABLES_ADMIN权限（不是SYSTEM_VARIABLES_ADMIN） - 它不校验参数合法性，只存值；如果写错（如
server_id=0），重启直接失败并报错ERROR 2002 (HY000)连不上 - 它不会覆盖
my.cnf中已存在的同名配置，冲突时以my.cnf为准
所以，生产环境改 server_id 时，更稳妥的做法仍是手动编辑 my.cnf 并验证语法（mysqld --defaults-file=/etc/my.cnf --validate-config）。
热加载后还要做什么？
改完别急着走。几个容易被跳过的动作：
- 确认是否真生效：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';和SELECT * FROM performance_schema.variables_info WHERE VARIABLE_NAME = 'innodb_buffer_pool_size';对比VARIABLE_VALUE与LAST_UPDATE_TIMESTAMP - 检查
mysqld-auto.cnf文件权限是否为mysql:mysql且不可被其他用户写入（防止被篡改） - 若用的是容器或云数据库（如阿里云 RDS、AWS RDS），
SET PERSIST可能被禁用 —— 这类平台通常只开放白名单参数，且持久化靠控制台而非本地文件
最常被忽略的一点：热加载只影响新连接或后续行为，已存在的长连接、正在执行的事务、预编译语句缓存都不受触发。比如你调大了 sort_buffer_size，但某个慢查询已经卡在磁盘排序阶段，它的内存分配不会回滚重来。
