MySQL实际加载的是第一个存在的my.cnf文件，可通过mysqld --verbose --help | grep "Default options"查看搜索顺序，如/etc/my.cnf→/etc/mysql/my.cnf→~/.my.cnf，仅首个存在者生效。
如何确认MySQL实际加载的是哪个my.cnf文件
MySQL只读第一个存在的配置文件，不是你改的那个就全白干。运行 mysqld --verbose --help | grep "Default options"，输出里会列出按顺序查找的路径，比如 /etc/my.cnf → /etc/mysql/my.cnf → $MYSQL_HOME/my.cnf → ~/.my.cnf，它只取第一个存在的，后面的全忽略。
常见误操作包括：
- 在
/home/user/my.cnf里改了参数，但系统实际加载的是/etc/my.cnf -
/etc/my.cnf和/etc/mysql/my.cnf同时存在，MySQL只认前者，后者里的innodb_buffer_pool_size修改完全不生效 - 用
mysql --defaults-file=手动指定配置能启，但systemctl start mysql仍失败——因为服务脚本不走这个参数
用--validate-config快速验证配置合法性
别靠反复重启试错。MySQL 5.7.20+ 和 8.0.14+ 支持 --validate-config，直接检查语法和参数有效性：
mysqld --defaults-file=/etc/my.cnf --validate-config
它会立刻报出问题，比如：
-
unknown variable 'query_cache_size'（MySQL 8.0+ 已移除该参数） -
option not recognized: 'max_connection'（少了个s，应为max_connections） -
Incorrect argument type for innodb_buffer_pool_size（写成2g或2GB，8.0+ 要求单位大写：2G） -
Option 'datadir' used in group 'client'（datadir只能在[mysqld]段生效）
为什么配置文件权限不对会导致服务静默失败
MySQL启动时会主动拒绝加载 world-writable 的配置文件。只要 /etc/my.cnf 权限是 664（组可写）、666 或更宽松，就会出现日志里完全没报错、但服务起不来的情况，错误日志中可能只有一句：World-writable config file '/etc/my.cnf' is ignored。
修复方式很简单：
- 查当前权限：
ls -l /etc/my.cnf - 收紧权限：
sudo chmod 644 /etc/my.cnf - 确保属主是
root：sudo chown root:root /etc/my.cnf
注意：即使其他配置都对，只要权限不合规，MySQL 就跳过整个文件，回退到内置默认值——这意味着 datadir、log-error 等关键路径全部失效。
错误日志里第一个[ERROR]往往就是根因
别扫完整个日志。MySQL 启动失败时，错误日志（如 /var/log/mysqld.log）开头几行通常就藏着关键线索：
-
[ERROR] unknown variable 'version_comment=mysql server'→ 配置里写了废弃或拼错的变量 -
[ERROR] Failed to open required defaults file→ 配置路径不存在，或权限被拒 -
[ERROR] Can't start server: Bind on TCP/IP port: Address already in use→ 3306 被占，但注意：这可能是前一次启动残留的进程没退出干净 -
[ERROR] InnoDB: The Auto-extending innodb_system data file './ibdata1' is of a different size→innodb_data_file_path改了但没清理旧文件
真正容易被忽略的是：有些“警告”其实是致命的前置条件，比如 [Warning] World-writable config file ... is ignored 出现在日志开头，后面所有基于该配置的设置（包括 log-error 路径）都会失效，导致后续报错定位困难。
