MySQL实际加载的是搜索顺序中第一个存在且权限合法的my.cnf文件，路径顺序为/etc/my.cnf→/etc/mysql/my.cnf→$MYSQL_HOME/my.cnf→~/.my.cnf；运行mysqld --verbose --help | grep "Default options"可确认真实加载路径。
MySQL 服务没加载你改过的 my.cnf，大概率不是配置写错了，而是根本没读到那个文件。
MySQL到底在用哪个my.cnf？
它不会自动扫描所有可能路径，而是按固定顺序查找，并只加载第一个匹配的文件（除非显式指定多个）。常见误判是：你改了 /etc/my.cnf，但它实际加载的是 ~/.my.cnf 或 /etc/mysql/my.cnf —— 尤其在 Debian/Ubuntu 系统上，后者才是默认主配置文件。
- 查真实加载路径最可靠的方式是运行：
mysqld --help --verbose | grep "Default options"，输出里列出的顺序就是实际搜索顺序 - 如果 MySQL 正在运行，也可以连上去执行：
SELECT @@global.config_file;（MySQL 8.0.22+）或检查SHOW VARIABLES LIKE 'datadir';后推断，但不如前者直接 - 注意：
--defaults-file参数一旦出现，会跳过所有其他路径，只读该文件 —— 检查systemctl cat mysqld或ps aux | grep mysqld看启动命令里有没有这个参数
[client] 和 [mysql] 段配置不生效？
这两个段不是“都能控制 mysql 命令行工具”的关系，而是有明确作用域和覆盖逻辑：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
[client]被所有客户端程序共享（mysql、mysqldump、mysqladmin等），但仅影响连接参数（如host、user、port、default-character-set） -
[mysql]只作用于mysql命令行客户端本身，可覆盖[client]中同名参数（比如你在[mysql]里设了prompt="\u@\h [\d]> "，[client]里的prompt就无效） - 如果你改了
[client]的port却发现mysql -u root -p还连 3306，很可能是因为你没加-P参数，而mysql默认优先读[mysql]段；或者你改的文件根本没被加载
改完配置没生效，重启服务也不行？
别急着怀疑语法，先确认三件事：
- 配置文件权限是否正确？MySQL 服务进程（通常是
mysql用户）必须有读取权限。常见坑：chmod 600 ~/.my.cnf后，mysqld进程无法读用户家目录下的文件（它以mysql用户身份运行，不是你的用户） - 修改的是
[mysqld]段吗？只有这个段控制服务端行为（如bind-address、max_connections）。改[client]段永远不影响服务监听地址或端口 - 是否遗漏了
skip-grant-tables或!includedir导致配置被覆盖？例如 Ubuntu 的/etc/mysql/my.cnf末尾常有!includedir /etc/mysql/conf.d/，你改的主文件可能被/etc/mysql/conf.d/50-server.cnf里同名参数覆盖
最容易被忽略的一点：MySQL 服务加载配置是一次性的，发生在启动时。哪怕你改对了文件、改对了段、改对了参数，只要没真正重启服务（systemctl restart mysqld），旧进程就继续用旧内存里的配置。而有些系统（如某些容器环境）甚至会把配置文件挂载为只读，改了也白改。
