SET PERSIST 可持久化事务参数如 innodb_flush_log_at_trx_commit，写入 mysql.persisted_variables 表，重启自动加载，优先级高于配置文件；SHOW PERSISTED VARIABLES 可核查，RESET PERSIST 可安全回滚。
因为持久化参数能让事务相关系统变量在重启后不丢失，避免手动改配置文件的遗漏和误操作。
SET PERSIST 能直接固化事务行为参数
像 innodb_flush_log_at_trx_commit、sync_binlog 这类控制事务持久性强度的核心参数，直接影响数据是否真正落盘。以前必须写进 /etc/my.cnf 才能持久，现在可直接运行：
SET PERSIST innodb_flush_log_at_trx_commit = 1;
这条命令会把值写入内部系统表 mysql.persisted_variables，下次启动自动加载。不需要停服、不用编辑配置文件、不会因忘记同步多台实例而出现配置漂移。
- 只对具备
SYSTEM_VARIABLES_ADMIN权限的用户生效 - 设置后立即影响新连接，但当前会话仍用旧值（需重新连接验证）
- 若同时在配置文件里写了同名参数，
SET PERSIST的值优先级更高
SHOW PERSISTED VARIABLES 可快速核验关键事务配置
运维或DBA在巡检时，常需确认“生产库是否真的启用了强持久模式”。用传统方式得去翻配置文件、再查运行时值，容易漏掉差异。现在只需：
SHOW PERSISTED VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
就能明确知道该参数是否被持久化、值是多少。配合 SELECT @@innodb_flush_log_at_trx_commit; 对比，可一眼识别出“配置已设但未生效”或“配置被覆盖”的异常状态。
- 注意：
SHOW PERSISTED VARIABLES不显示未被持久化的变量，哪怕它当前运行值是 1 - 如果返回空结果，说明该变量从未被
SET PERSIST过，哪怕你刚在配置文件里改了
RESET PERSIST 可安全回滚误调优的事务参数
调参不是一锤子买卖。比如把 sync_binlog = 1 持久化后发现写入吞吐骤降，又不敢贸然删配置文件——怕删错行或格式出问题。这时：
RESET PERSIST sync_binlog;
就能立刻清除持久化记录，MySQL 启动时将回落到配置文件中的值（或默认值）。整个过程不重启、不改磁盘文件、无语法风险。
- 执行后需手动执行
SET GLOBAL sync_binlog = 0才能即时生效（否则仍沿用原持久值直到重启） -
RESET PERSIST不影响当前运行值，只清内部表记录 - 若配置文件中也写了该参数，清除持久化后，以配置文件为准
真正容易被忽略的是：持久化变量只保存值，不保存上下文。比如你在压测时临时设了 innodb_log_file_size = 2G 并持久化，但没同步调整 innodb_log_files_in_group 或清理旧日志，重启可能直接失败。调事务参数，从来不是单点操作，而是配置组合的闭环验证。
