MySQL实际加载的是搜索顺序中第一个存在且权限合法的my.cnf文件，运行mysqld --verbose --help | grep "Default options"可查看确切路径顺序。
确认MySQL实际加载了哪个my.cnf文件
改完配置却没生效，第一反应不该是“是不是写错了”，而是“MySQL压根就没读你改的这个文件”。MySQL 8.0 启动时只按固定顺序扫描几个路径，找到第一个存在且语法合法的就停，后续全忽略。
运行 mysqld --verbose --help | grep "Default options"，输出类似 /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf —— 注意顺序，它只认第一个存在的。
- Linux 常见但易错：你改了
/usr/etc/my.cnf，但它根本不在默认搜索路径里 - Docker 容器里必须
docker inspect 容器名看挂载点，宿主机文件没映射进去，改了等于白改 - Windows 下优先级最高的是
%PROGRAMDATA%\MySQL\MySQL Server 8.0\my.ini，很多人改了安装目录下的my.ini却没生效 - 如果进程启动时带了
--defaults-file=/xxx/my.cnf，那其他所有路径都作废，只认这个
检查配置语法、段落和权限是否合规
MySQL 对配置格式极其敏感，出一点小错就静默跳过整行甚至整个段落，日志里往往只报 unknown variable 或直接不提示。
必须确保：
-
[mysqld]段头独占一行，不能有空格或注释（[mysqld ]或# [mysqld]都无效） - 参数写在
[mysqld]下，不是[client]或[mysql]—— 比如bind-address放错段就完全不生效 - 等号两边可有空格，但不能用冒号、不能省略等号、不能加引号（
log_error = "/var/log/mysqld.log"反而可能失败） - 文件权限不能是 world-writable：
chmod 644 /etc/my.cnf，否则 MySQL 直接跳过并用内置默认值 - 用
mysqld --defaults-file=/etc/my.cnf --validate-config快速校验语法（MySQL 5.7.20+/8.0.14+ 支持）
区分参数类型：哪些必须重启，哪些可以 SET GLOBAL
不是所有参数改了配置文件都要重启，也不是所有参数都能运行时改。混淆这两类，就会误判“没生效”。
例如：
-
max_connections是动态参数，可SET GLOBAL max_connections = 200立即生效，但不写进my.cnf的话，重启就回退 -
innodb_log_file_size是静态参数，改了my.cnf必须重启，且SET GLOBAL会报错Variable 'innodb_log_file_size' is a read only variable -
sql_mode写在[mysqld]下只影响新连接；已存在的连接仍用旧值，需重连才体现 -
lower_case_table_names在 MySQL 8.0 中属于初始化后不可变更项，改了my.cnf会导致启动直接失败（报错[MY-011087]），不是“不生效”，是拒绝启动
验证运行时值是否真被采纳
别只信配置文件写了什么，要看 MySQL 当前实际用的是什么值。最可靠的方式是进 MySQL 执行：
SELECT @@global.config_file;（MySQL 8.0.21+）—— 直接告诉你它加载的是哪个文件
SHOW VARIABLES LIKE '参数名'; —— 比如 SHOW VARIABLES LIKE 'bind_address';，看返回值是不是你设的 0.0.0.0
- 如果
config_file返回空，说明 MySQL 没加载任何配置文件，靠的是编译默认值或命令行参数 - 如果
bind_address显示127.0.0.1，再查skip_networking是否为ON（它会强制关闭 TCP 栈） - 远程连不上？用
ss -tlnp | grep :3306看监听地址，只显示127.0.0.1:3306就说明 bind 没生效或被覆盖
最容易被忽略的是：云服务器的安全组、本地防火墙（ufw/firewalld）、以及 MySQL 用户认证插件（如 caching_sha2_password 不被老版 Navicat 支持）—— 这些和 my.cnf 无关，但会让“配置看似生效却连不上”。
