MySQL配置生效需验证三点：语法无误、被正确加载、运行时值如预期；执行SHOW VARIABLES确认实际值，mysqld --verbose --help | grep "Default options"定位加载路径，SELECT @@global.config_file查主配置文件，再核对参数是否在[mysqld]段并检查错误日志警告。
配置参数写进 my.cnf 不等于生效，MySQL 启动时可能跳过、忽略甚至报错却不退出。验证是否“正确”，核心是确认三点：语法无误、被加载、最终值如预期。
查运行时值：SHOW VARIABLES 是唯一真相
文件里写了 max_connections = 2000，不代表它真起效了。MySQL 启动后合并了所有来源（命令行、多个配置文件、动态设置），SHOW VARIABLES 返回的是最终拍板的值。
- 登录后执行
SHOW VARIABLES LIKE 'max_connections';—— 看到的才是当前实例实际用的值 - 想查全部？用
mysql -u root -p -e "SHOW VARIABLES;" | grep max_connections过滤，避免刷屏 - 注意区分作用域：
SELECT @@global.max_connections;和SELECT @@session.max_connections;可能不同，尤其对会话级参数（如sort_buffer_size）
定位配置来源：别改了错的文件
MySQL 按固定顺序读取多个配置文件，~/.my.cnf 和 /etc/my.cnf 都存在时，后者优先；但如果你用 mysqld --defaults-file=/tmp/my.cnf 启动，就只认这个。
- 运行
mysqld --verbose --help | grep "Default options"，看它实际搜哪些路径（常见有/etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf） - MySQL 8.0.22+ 可直接查：
SELECT @@global.config_file;，返回主配置文件绝对路径 - 检查该文件中参数是否在
[mysqld]段落内——写在[client]或文件开头没加段落，会被完全忽略
看错误日志：启动失败或静默失效的线索全在这
配置写错，MySQL 很少直接崩溃退出，而是记一条警告然后跳过那行。不看日志，你永远不知道它“假装”读了你的配置。
- 先查日志位置：
SELECT @@global.log_error; - 打开日志（如
/var/log/mysql/error.log），搜索关键词：unknown variable、option ignored、invalid value - 典型坑：
innodb_buffer_pool_size = 2G正确，但写成2g或2GB可能被忽略；max_allowed_packet = 64M对，= 64MB就错 - 重启服务后立刻查日志——哪怕启动成功，也可能有 “
Warning” 级别提示
验证动态参数：SET GLOBAL 能否立即生效
不是所有参数都能热更新。用 SET GLOBAL 试一下，是最快判断参数是否“被识别且支持动态”的方式。
- 执行
SET GLOBAL wait_timeout = 300;，再SHOW VARIABLES LIKE 'wait_timeout';—— 值变了，说明参数名对、类型对、权限够 - 如果报错
ERROR 1238 (HY000): Variable 'xxx' is a read only variable，就是静态参数，必须重启 - 查官方文档或运行
SELECT VARIABLE_NAME, VARIABLE_SCOPE FROM performance_schema.variables_info WHERE VARIABLE_NAME = 'xxx';，VARIABLE_SCOPE为GLOBAL或BOTH才支持动态
最容易被跳过的其实是错误日志里的警告——它不阻止启动，但让配置形同虚设。每次改完 my.cnf，三件事必须做：重启服务、查错误日志、再跑一遍 SHOW VARIABLES。少一步，就等于没改。
