最直接确认mysql是否读取my.cnf的方法是执行show variables like 'config_file';，若返回空或null则未加载任何配置文件；否则检查返回路径是否存在及权限、编码、换行符等。
MySQL启动时根本没读my.cnf，怎么确认？
最直接的办法是连上 MySQL 后执行 SHOW VARIABLES LIKE 'config_file';。如果返回空值或 NULL，说明 MySQL 根本没加载任何配置文件；如果返回路径但该路径不存在，就是配置文件被删了或路径写错了。
另一个关键线索是启动日志：用 mysqld --verbose --help | grep "Default options" 查看 MySQL 编译时硬编码的默认搜索路径（通常是 /etc/my.cnf、/etc/mysql/my.cnf、/usr/etc/my.cnf、~/.my.cnf），它按顺序扫描，**找到第一个就停，不会合并多个**。
Linux 下 mysqld 实际按什么顺序找 my.cnf？
运行 mysqld --verbose --help | grep -A 1 "Default options"，输出类似：
Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf /usr/local/etc/my.cnf ~/.my.cnf
这个顺序不可改，但你可以往其中任一存在且可读的路径放一个最小可用的 my.cnf。注意：
-
/etc/my.cnf是系统级通用路径，适合全局服务配置 -
/etc/mysql/my.cnf在 Debian/Ubuntu 系统中更常见 -
~/.my.cnf只影响当前用户执行的客户端命令（如mysql -u root），对mysqld启动无效 - macOS Homebrew 安装默认走
/usr/local/etc/my.cnf，不是/etc/my.cnf
rpm 或 deb 包安装后为什么没有 my.cnf？
这是正常现象——MySQL 安装包不强制创建配置文件，而是依赖内置默认参数启动。RPM 包通常把模板文件放在 /usr/share/mysql/my-medium.cnf 等位置，但不会自动复制到搜索路径中。
快速补救方法：
- 复制模板：
sudo cp /usr/share/mysql/my-medium.cnf /etc/my.cnf - 或手动生成最小可用配置（必须含
[mysqld]段）：
[mysqld] datadir = /var/lib/mysql socket = /var/lib/mysql/mysql.sock user = mysql
注意：datadir 路径权限必须为 mysql:mysql，且目录需存在；socket 路径的父目录也需可写。
--defaults-file 强制指定却报错 File '/xxx/my.cnf' not found
这个参数要求路径必须绝对且文件必须存在，且不能有任何注释或空行在第一行——MySQL 解析器会在读到第一个非空白/非注释行前拒绝加载。
常见坑点：
- 路径写成相对路径（如
./my.cnf），必须用绝对路径（如/opt/mysql/conf/my.cnf） - 文件首行是
#注释或空行，MySQL 直接跳过并报错“not found” - systemd 服务中修改
ExecStart时未加引号，导致空格被截断 - Docker 官方镜像默认不挂载配置，
docker run mysql会完全忽略宿主机的my.cnf
真正生效的配置路径，永远取决于 ps -ef | grep mysqld 里实际出现的 --defaults-file= 参数，而不是你“以为”它该读哪里。
