真正有用的配置文件路径在 mysql --verbose --help 输出中紧随“Default options are read from the following files in the given order:”的那行，其后逗号分隔的路径即客户端实际查找顺序。
mysql --verbose 输出里哪行才是配置文件路径
执行 mysql --verbose --help 时，输出极长，真正有用的只有一行：开头附近紧跟着 Default options are read from the following files in the given order: 的那行。它后面列出的路径（用逗号分隔）就是 MySQL 客户端实际查找配置文件的顺序。
常见错误是盯着最后的 –defaults-file= 或 –defaults-extra-file= 看——这些是手动指定的，不是“当前默认用的”。没显式指定时，才轮到上面那行列出的路径。
-
~/.my.cnf和/etc/my.cnf最常被修改，但优先级不同：用户家目录的.my.cnf会覆盖系统级的/etc/my.cnf - Windows 下对应的是
%WINDIR%\my.ini或C:\my.cnf，顺序也按那行输出为准 - 如果某路径不存在，MySQL 就跳过它，不报错也不提示
mysqld 启动时读哪个配置文件
mysql 客户端和 mysqld 服务端读的配置文件不完全一样。查服务端用的配置，不能只看 mysql --verbose --help，得用 mysqld --verbose --help，同样找 Default options are read from... 那行。
关键区别在于：服务端默认还会检查 /etc/mysql/my.cnf（Debian/Ubuntu 系）、/usr/etc/my.cnf（部分编译安装），而客户端通常不读这些。
- 运行中的
mysqld进程实际加载了哪些配置，可查SELECT @@global.config_file;（5.7+），但注意：这个值只反映启动时解析的第一个有效配置文件，不是全部 - 若用
systemd启动，还要确认mysqld.service是否通过--defaults-file覆盖了默认行为 - Docker 容器里跑的
mysqld，往往把配置挂载到/etc/mysql/conf.d/下的单独文件，这时主my.cnf可能只是个空壳
为什么改了 /etc/my.cnf 没生效
最常见原因是：你改的是客户端配置，但想影响的是服务端行为（比如 max_connections），或者反过来。另一个高频坑是权限——mysqld 进程以 mysql 用户运行，如果 /etc/my.cnf 所有者是 root 且权限设成 600，它根本读不了。
- 修改后必须重启
mysqld（不是mysql客户端），否则配置不会重载 - 用
mysqld --print-defaults可看到最终合并后的所有生效参数，比猜更可靠 - 如果配置里写了
[client]段，它只影响客户端；[mysqld]段才影响服务端；[mysql]段只影响mysql命令行工具本身
如何确认某个配置项到底来自哪个文件
MySQL 不提供“这个变量从哪行、哪个文件读来的”追踪功能。但可以靠排除法缩小范围：mysqld --verbose --help 输出中，同一参数可能出现多次（比如在不同段落下），优先级高的段落会覆盖低的。
更直接的办法是逐个注释掉可疑配置文件里的段落，再用 mysqld --print-defaults | grep 参数名 观察变化。例如：
mysqld --print-defaults | grep max_connections
如果输出为空，说明该参数用了内置默认值；如果出现，就说明至少有一个配置文件启用了它。
复杂点在于：同一个参数可能被多个文件定义，而 MySQL 只取最后一个有效值——不是第一个，也不是最“权威”的那个。容易被忽略的是：命令行参数 > [mysqld] 段 > [server] 段 > 全局段，这种隐式覆盖链很难一眼理清。
