MySQL启动时按固定顺序读取第一个存在的my.cnf文件，典型路径为/etc/my.cnf→/etc/mysql/my.cnf→/usr/local/mysql/etc/my.cnf→~/.my.cnf；使用--defaults-file可强制只读指定文件。
mysql 启动时到底读哪个 my.cnf
MySQL 不是只读一个配置文件，而是按固定顺序扫描多个路径，找到第一个存在的就停止——后面路径的同名文件根本不会被加载。这个顺序在不同安装方式（源码编译、官方二进制包、Linux 发行版包如 apt/yum）下略有差异，但核心逻辑一致。
常见路径（按典型 Linux 官方二进制包顺序）：/etc/my.cnf → /etc/mysql/my.cnf → /usr/local/mysql/etc/my.cnf → ~/.my.cnf
- Windows 下是
my.ini或my.cnf，优先级类似：%WINDIR%\my.ini → C:\my.cnf →BASEDIR\my.cnf -
mysqld --help --verbose | grep "Default options"可直接看到当前二进制实际扫描路径（最准） - 如果用
mysqld --defaults-file=<code>/path/to/my.cnf启动，则**只读这一个文件**，完全跳过默认顺序
如何确认 MySQL 实际加载了哪份配置
别猜，直接问 MySQL 自己。连上后执行：SELECT @@global.config_file; —— 仅 8.0.29+ 支持
更通用的办法是查变量来源：SHOW VARIABLES LIKE 'datadir'; 配合 SHOW VARIABLES LIKE 'socket'; 等关键项，反推配置是否生效
- 启动时加
--print-defaults（例如mysqld --print-defaults）会输出最终合并后的所有参数，不含注释但能看出哪些文件被读取 - 错误日志里通常有类似
mysqld: Can't read dir of '/etc/mysql/conf.d/' [Errno 2]这种提示，说明它尝试过该路径 - 修改配置后必须重启
mysqld进程（不是mysql客户端），且注意 systemd 管理的实例要用sudo systemctl restart mysql，而非直接 kill
想换配置文件路径，但不想改系统默认位置
最稳妥的方式不是移动或软链 my.cnf，而是用启动参数锁定路径。尤其适用于多实例、容器或开发测试环境。
- 启动命令中显式指定：
mysqld --defaults-file=/opt/mysql/my-prod.cnf - systemd 服务中，在
[Service]段加ExecStart=覆盖（注意保留原参数，比如ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/my.cnf --user=mysql） - Docker 中通过
command: ["--defaults-file=/etc/mysql/my-custom.cnf"]传入 - 不要用
alias mysql='mysql --defaults-extra-file=...'这类客户端侧方案来“覆盖服务端配置”——它只影响客户端行为，对 mysqld 无效
my.cnf 里写错路径或权限不对，MySQL 直接不起来
这是最常卡住人的点：配置文件语法没错，但指向的目录不存在、文件不可读、用户无权限，mysqld 就会静默失败（日志里可能只有 Aborting 或空启动）。
-
pid-file、socket、datadir、log-error这些路径对应的目录必须存在，且mysqld运行用户（通常是mysql）有读写权限 - 用
sudo -u mysql ls -l /path/to/dir检查权限，比看ls -l更真实 -
log-error路径写错时，错误日志本身都写不出，此时只能靠strace -f -e trace=openat,openat64 mysqld --defaults-file=... 2>&1 | grep -i deny抓系统调用级拒绝信息 - SELinux 或 AppArmor 开启时，即使权限正确也会拦截，先临时
setenforce 0测试是否为此类问题
路径和权限问题永远比语法问题更难定位，因为没报错信息。每次改完配置，第一反应不该是连客户端，而是看 ps aux | grep mysqld 和 tail -n 20 /var/log/mysql/error.log。
