生产环境不能直接 set global 就完事，必须确认变量是否支持动态修改（如 innodb_buffer_pool_size 可，innodb_log_file_size 不可）、是否影响现有连接（仅新连接生效）、权限是否充足（需 system_variables_admin 或 super）、是否持久化（推荐 set persist 或手动改配置文件并重启）。
生产环境不能直接 SET GLOBAL 就完事，必须区分变量是否支持动态修改、是否影响现有连接、是否需重启，以及有没有权限和持久化保障。
确认变量是否支持动态修改（SET GLOBAL 是否可用）
不是所有全局变量都能运行时改。比如 innodb_buffer_pool_size 在 MySQL 5.7+ 支持动态调整，但 innodb_log_file_size 是静态变量，SET GLOBAL 会报错 ERROR 1238 (HY000): Variable 'innodb_log_file_size' is a read only variable。
- 查文档或执行
SHOW VARIABLES LIKE 'variable_name'后，再看SELECT VARIABLE_NAME, VARIABLE_SCOPE FROM performance_schema.variables_info WHERE VARIABLE_NAME = 'max_connections'——VARIABLE_SCOPE值为GLOBAL且非READ ONLY才可动态设 - 常见可动态改的：
max_connections、wait_timeout、sort_buffer_size（注意：后者改的是新连接的默认值，已有连接不受影响） - 常见不可动态改的：
server_id、datadir、innodb_data_file_path
在线修改前必须验证权限与作用范围
用 SET GLOBAL 需要 SUPER 或 SYSTEM_VARIABLES_ADMIN 权限（MySQL 8.0.16+ 推荐后者），且修改只影响**后续新建连接**，已存在的连接仍沿用旧的会话变量值。
- 执行前先检查权限：
SHOW GRANTS FOR CURRENT_USER，确认含SYSTEM_VARIABLES_ADMIN或SUPER - 改完后立刻验证：
SHOW GLOBAL VARIABLES LIKE 'max_connections'看是否生效；再开一个新连接，执行SHOW VARIABLES LIKE 'max_connections'确认新连接已继承 - 别指望改了
innodb_buffer_pool_size就立刻释放/占用内存——它按 chunk 动态增减，实际生效可能有延迟，且不会低于最小值（如 5MB）
必须同步写入配置文件并计划重启（除非用 SET PERSIST）
SET GLOBAL 是临时的，MySQL 意外崩溃或计划内重启后就回滚。生产环境必须让变更“落地”，否则等于没做。
- 优先用
SET PERSIST variable_name = value（MySQL 8.0.14+ 支持）：它会自动把值写入mysqld-auto.cnf，重启后自动加载，无需人工编辑配置文件 - 若版本不支持
SET PERSIST，必须手动改my.cnf（Linux）或my.ini（Windows）的[mysqld]段落，例如：[mysqld] max_connections = 1000 wait_timeout = 300
，然后systemctl restart mysql - 改配置文件前务必
cp /etc/my.cnf /etc/my.cnf.bak-$(date +%Y%m%d)备份；段落错位（比如写到[client]下）会导致 mysqld 启动失败
避免踩坑的关键细节
看似简单的变量修改，线上出问题往往卡在几个隐性环节。
-
SET GLOBAL不校验值合法性，比如设max_connections = -1不报错，但后续连接会失败；务必提前查官方文档允许范围 - 内存类变量如
innodb_buffer_pool_size，设得太大可能触发 OOM Killer 杀掉 mysqld 进程，建议留至少 2GB 给 OS 和其他服务 - 某些变量修改后需配合其他操作才真正起效：比如调大
max_connections后，OS 层的ulimit -n也要同步提高，否则 MySQL 仍无法打开足够文件描述符 - 主从架构下，
server_id、log_bin这类变量必须主从不一致且不能动态改，强行 SET 会破坏复制
