答案是修改MySQL全局变量需先用SET GLOBAL即时生效，再将变量写入my.cnf或my.ini的[mysqld]段落并重启服务以持久化；区分全局与会话变量在于作用范围，前者影响整个实例且需SUPER权限，后者仅限当前会话；配置文件操作应备份、注释清晰、避免语法错误和段落错位，并通过错误日志排查问题。
修改MySQL的全局变量并确保这些更改在服务重启后依然生效，核心在于两个步骤：首先是使用
SET GLOBAL命令进行即时修改，这只在当前运行实例中有效；其次，也是最关键的，是将这些修改写入到MySQL的配置文件（如
my.cnf或
my.ini）中，并在
[mysqld]段落下定义，然后重启MySQL服务，这样才能实现持久化。
解决方案
修改MySQL的全局变量，这事儿说起来简单，但真要做到位，特别是要让它重启后依然生效，这里面其实有些细节和“坑”需要留意。我个人在处理这类问题时，通常会分两步走，确保万无一失。
首先，即时生效的修改。当你需要一个变量立即生效，比如调整
max_connections来应对突发的连接高峰，或者临时性地开启
log_bin进行故障排查，
SET GLOBAL语句就是你的首选。
SET GLOBAL max_connections = 500; -- 或者 SET @@global.max_connections = 500;
这两种写法都可以，效果是一样的。执行这条命令后，
max_connections这个全局变量会立刻变为500。你可以通过
SHOW GLOBAL VARIABLES LIKE 'max_connections';来验证。需要注意的是，这种修改只在当前MySQL实例运行期间有效。一旦MySQL服务重启，这个变量就会恢复到其配置文件中定义的值，或者如果没有定义，则恢复到MySQL的默认值。这就是为什么我们不能只依赖
SET GLOBAL。
接着，是持久化配置。这才是真正让你的修改“活”下来的关键。我们需要修改MySQL的配置文件。在Linux系统上，这个文件通常是
/etc/my.cnf、
/etc/mysql/my.cnf，或者是MySQL数据目录下的
my.cnf。Windows系统上则可能是
my.ini。如果你不确定你的MySQL实例到底加载了哪个配置文件，可以通过
SHOW VARIABLES LIKE 'config_file';或者查看
mysqld进程的启动参数来确认。
找到配置文件后，你需要找到或创建一个
[mysqld]段落。在这个段落下，添加或修改你想要持久化的全局变量。 例如，要让
max_connections永久设置为500，你会在
my.cnf中加入：
[mysqld] max_connections = 500
保存文件后，你需要重启MySQL服务。 在Linux上，通常是：
sudo systemctl restart mysql或
sudo service mysql restart重启完成后，再次登录MySQL，使用
SHOW GLOBAL VARIABLES LIKE 'max_connections';验证，你会发现它依然是500。
这里有个我踩过的坑：有些变量是动态的，可以用
SET GLOBAL修改；有些变量是静态的，必须通过配置文件修改并重启服务才能生效。如果你尝试用
SET GLOBAL修改一个静态变量，MySQL会报错。所以，在修改前，最好查阅一下MySQL官方文档，了解该变量的动态性。
如何区分MySQL全局变量与会话变量，以及它们各自的修改方式？
理解MySQL的变量体系，是进行有效配置的基础。我们通常会接触到两类主要的变量：全局变量（Global Variables）和会话变量（Session Variables）。它们在作用域、生命周期以及修改方式上都有显著的区别。
全局变量，顾名思义，是影响整个MySQL服务器实例的变量。它们在MySQL服务器启动时从配置文件（
my.cnf等）加载，或者使用默认值。所有连接到这个MySQL服务器的客户端，都会受到这些全局变量的约束或影响。比如
max_connections决定了服务器能接受的最大并发连接数，
innodb_buffer_pool_size影响了InnoDB存储引擎的性能，这些都是全局性的配置。修改全局变量通常需要
SUPER权限。
会话变量，则只对当前的客户端连接（即当前会话）有效。每个新的客户端连接建立时，会话变量会从对应的全局变量中继承初始值。但一旦在会话内部修改了某个会话变量，这个修改只对当前这个会话生效，不会影响其他并发连接，也不会影响全局变量的值。例如，你可能在一个特定的会话中，为了调试或执行某个特定的任务，临时将
sql_mode修改为
TRADITIONAL模式：
SET SESSION sql_mode = 'TRADITIONAL'; -- 或者 SET @@session.sql_mode = 'TRADITIONAL';
这个修改只对你当前的这个连接有效。一旦你断开连接，或者重新建立一个新的连接，
sql_mode就会恢复到全局变量所定义的值。
修改方式上：
-
全局变量：
-
即时生效（非持久化）： 使用
SET GLOBAL var_name = value;
。这种方式修改后立即生效，但服务器重启后会失效。 -
持久化生效： 修改MySQL的配置文件（
my.cnf
或my.ini
），在[mysqld]
段落中添加或修改var_name = value
，然后重启MySQL服务。这是确保修改永久生效的唯一途径。
-
即时生效（非持久化）： 使用
-
会话变量：
-
即时生效（仅当前会话）： 使用
SET SESSION var_name = value;
或者SET var_name = value;
（当SET
后面没有GLOBAL
或SESSION
时，默认是修改当前会话变量）。这种修改只对当前连接有效，连接断开后即失效。
-
即时生效（仅当前会话）： 使用
我个人的经验是，在日常运维中，如果只是为了临时测试或调试，我会倾向于使用
SET SESSION，因为它不会影响到其他正在运行的业务。但如果是涉及到系统性能优化、安全策略调整等需要长期生效的配置，那么修改配置文件并重启服务是必经之路。混淆这两者，轻则配置不生效，重则可能导致服务行为异常。
MySQL配置文件（my.cnf/my.ini）的最佳实践与常见陷阱有哪些？
处理MySQL配置文件，这活儿看着简单，但里面学问不少。我个人在管理
my.cnf时，总结了一些最佳实践，也踩过不少坑，希望能给大家提个醒。
最佳实践：
定位准确的配置文件： 这是第一步，也是最容易出错的一步。MySQL可能加载多个配置文件，或者根本不是你以为的那个。我通常会用
mysql --help | grep "Default options"
来查看MySQL启动时搜索配置文件的路径顺序，或者更直接地，通过SHOW VARIABLES LIKE 'config_file';
（虽然这个变量在某些版本或配置下可能不显示具体路径，但可以作为参考）。最稳妥的方式是查看mysqld
进程的启动参数，通常会有一个-defaults-file
或-defaults-extra-file
指向实际使用的配置文件。备份是王道： 每次修改配置文件前，务必备份！我强调这一点，因为手滑改错配置导致MySQL无法启动的情况，我见过太多了。一个简单的
cp my.cnf my.cnf.bak_$(date +%F)
就能救你于水火。模块化配置： 当配置文件变得很长时，考虑将其拆分成多个小文件，例如
my.cnf
可以包含!include /etc/mysql/conf.d/*.cnf
。这样，你可以将不同功能的配置（如InnoDB配置、日志配置、复制配置等）放在不同的.cnf
文件中，便于管理和维护。这在/etc/mysql/conf.d/
目录下很常见。-
注释清晰： 在配置文件中添加详细的注释，说明每个参数的用途、修改原因、以及修改时间。这对于团队协作和日后审计都非常有帮助。
[mysqld] # 2023-10-27: Increased max_connections to handle peak traffic. # Original value was 151. max_connections = 500
增量修改： 尽量只修改你需要改变的参数，而不是复制粘贴整个默认配置。这样可以减少出错的概率，也更容易追踪变更。
版本兼容性： 不同的MySQL版本，某些参数的名称、默认值甚至行为都可能有所不同。在升级MySQL版本后，务必检查配置文件中的参数是否仍然适用。
常见陷阱：
-
错误的段落： 将
[mysqld]
下的配置写到了[mysql]
（客户端配置）或其他不相关的段落，导致参数不生效。这是非常低级的错误，但确实会发生。 -
语法错误： 拼写错误、等号前后多余的空格、或者使用了不被识别的参数名。MySQL启动时如果遇到严重的语法错误，可能会直接失败。检查
mysqld
的错误日志（通常是hostname.err
在数据目录下）是排查这类问题的关键。 -
权限问题： 配置文件本身或其所在目录的权限设置不当，导致MySQL无法读取。确保
mysql
用户对配置文件有读取权限。 - 遗漏重启： 修改了配置文件，但忘记重启MySQL服务。这是最常见的“为什么我的配置没生效”的原因。
-
参数冲突或重复： 在不同的配置文件中（如果使用了
!include
），或者在同一个文件中，重复定义了同一个参数。MySQL通常会以最后一个出现的值为准，但这会造成混淆，不易排查。 -
文件编码问题： 尤其是Windows环境下，如果
my.ini
文件保存为带有BOM的UTF-8格式，可能会导致MySQL无法正确解析。通常建议使用ANSI或无BOM的UTF-8编码。
我个人在遇到配置不生效时，第一反应就是去翻
mysqld的错误日志，几乎所有的启动问题、配置解析问题都会在那里留下痕迹
