mysql只读第一个存在且权限合规的my.cnf文件，路径顺序为/etc/my.cnf→/etc/mysql/my.cnf→$mysql_home/my.cnf→~/.my.cnf；权限含w（如666、777）会被静默忽略，参数须置于正确段落且拼写准确，修改后需正确重启并验证。
MySQL只读第一个存在的my.cnf文件
你改的配置文件很可能根本没被加载。MySQL启动时按固定顺序查找配置文件：/etc/my.cnf → /etc/mysql/my.cnf → $MYSQL_HOME/my.cnf → ~/.my.cnf，**只读第一个存在且权限合规的文件，其余全被忽略**。
常见踩坑点：
- 你在
/home/user/my.cnf里改了port = 3307，但MySQL实际加载的是/etc/my.cnf（哪怕它内容为空） - Ubuntu/Debian系默认用
/etc/mysql/my.cnf，而它常只是个入口文件，真正配置在/etc/mysql/mysql.conf.d/mysqld.cnf里 - 用
mysql --defaults-file=xxx能生效，但systemctl restart mysql仍走默认路径，两者不一致
验证方法：运行mysqld --verbose --help | grep "Default options"，输出里明确列出的才是真实加载路径。
配置文件权限过宽直接被跳过
MySQL会主动拒绝加载world-writable（全局可写）的配置文件。只要权限含w（比如664、644没问题，但666或777不行），就会报警告并跳过该文件，转而用内置默认值——这时你改的datadir、log-error等全失效。
典型错误日志：World-writable config file '/etc/mysql/mysql.conf.d/mysqld.cnf' is ignored
修复命令：chmod 644 /etc/mysql/mysql.conf.d/mysqld.cnf（注意不是755，目录可执行权限≠配置文件可执行权限）
额外注意：Docker挂载配置时，宿主机上文件权限若为644，但容器内MySQL用户无读权限，也会静默失败。
参数写错位置或已废弃
MySQL对配置段（section）和参数名极其敏感，放错地方或用错名，轻则无效，重则启动失败。
常见问题：
-
datadir只能写在[mysqld]段，写在[client]或[mysql]段会被忽略 - MySQL 8.0+已移除
query_cache_size，保留它会导致服务直接退出，日志只报unknown variable 'query_cache_size' -
innodb_buffer_pool_size = 2G正确，但写成2g（小写g）或2GB可能被忽略（8.0+严格区分大小写） -
max_connections少写一个s变成max_connection，参数不存在，启动失败
建议先用校验命令快速排查：mysqld --defaults-file=/etc/my.cnf --validate-config（5.7.20+/8.0.14+支持）
修改后没重启或重启方式不对
配置生效必须重启MySQL服务进程，但“重启”不等于systemctl restart mysql一定成功。
关键检查点：
- 确认服务是否真重启了：
systemctl status mysql看Active状态和启动时间 - 某些系统（如AWS RDS、阿里云RDS）不允许用户直接修改配置文件，需通过控制台或API操作
- 动态设置（如
SET GLOBAL server_id = 2）仅临时生效，MySQL重启后还原，必须写入配置文件并重启服务 - Windows下改
my.ini后，若服务未以管理员权限重启，可能因权限不足回退到默认配置
最保险的验证方式：改完配置后，用mysqld --defaults-file=/etc/my.cnf --console手动启动一次，看终端是否报错、是否读到你设的值。
mysqld --validate-config只能查语法，查不出路径错、权限错、段落错——这些得靠日志和手动验证来兜底。
