show variables 是唯一可信依据,它返回 mysql 当前实际生效的配置值,已合并配置文件、启动参数和动态设置;登录后执行 show variables like 'xxx'; 即可验证,结果中的 value 列为准。

直接查 SHOW VARIABLES 是唯一可信依据
配置文件改得再漂亮,SHOW VARIABLES 返回的值才是 MySQL 当前真正在用的。它合并了配置文件、启动参数、动态设置的结果,不依赖你“以为”写了什么。
登录后执行:mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"
或连接进客户端后输入:SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
注意:结果中的 Value 列就是最终生效值,不是配置文件里写的那个。
确认改的是 MySQL 实际加载的 my.cnf 路径
常见失效原因:你编辑的文件根本没被 MySQL 读到。不同安装方式路径差异极大,不能凭经验猜。
查真实加载路径:mysql --help | grep "Default options" —— 显示搜索顺序mysqld --verbose --help | grep "Default options" —— 更贴近服务端行为
MySQL 8.0.22+ 还可运行:SELECT @@global.config_file;(仅当配置文件确实被加载时返回非空)
如果返回 NULL 或空字符串,说明 MySQL 启动时压根没加载任何 my.cnf,所有配置都来自默认值或命令行参数。
重启后必须检查错误日志,否则可能静默失败
MySQL 遇到配置语法错误(比如单位写成 1G 写成 1g、漏括号、中文标点、参数名拼错)通常不会崩溃退出,而是跳过该行并记一条警告。
务必检查错误日志:SELECT @@global.log_error; 查出日志路径
然后看里面有没有类似:[Warning] option 'max_connections' has different value[Warning] unknown variable 'innodb_log_file_siz'(少了个 e)[Warning] option ignored
这些提示意味着你的修改被忽略了,但服务仍正常启动,极易被忽略。
区分哪些参数支持动态修改,哪些必须重启
不是所有参数都能靠 SET GLOBAL 立刻生效。验证前先查清楚:SELECT VARIABLE_NAME, VARIABLE_SCOPE FROM performance_schema.variables_info WHERE VARIABLE_NAME = 'max_connections';
返回 VARIABLE_SCOPE 是 GLOBAL 或 BOTH 才能动态改;SESSION 表示只能会话级生效;空值或 STATIC 表示必须重启。
典型静态参数:datadir、port、innodb_data_home_dir(5.7+ 部分 innodb_buffer_pool_size 支持动态但有约束,需满足内存对齐等条件)
动态改完立刻查:SET GLOBAL max_connections = 1000;SHOW VARIABLES LIKE 'max_connections';
但记住:这改的只是当前进程,重启就丢,要持久化还得写进 my.cnf 并重启。
最容易被绕开的环节是:没确认配置文件路径就开改,改完没看错误日志就认为成功,查变量时用了错的客户端连接方式(比如用 mysql -S /tmp/mysql.sock 连的是另一个实例)。三者缺一,验证就不可靠。











