最直接确认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 下普通用户启动时只认
~/.my.cnf，系统级配置对它无效 - macOS Homebrew 安装默认走
/usr/local/etc/my.cnf，不是/etc/my.cnf - Docker 官方镜像默认不挂载配置，
docker run mysql会完全忽略宿主机的my.cnf
用 --defaults-file 强制指定配置文件但报错 File '/xxx/my.cnf' not found
这个参数要求路径必须绝对且文件必须存在，且**不能有任何注释或空行在第一行**——MySQL 解析器会在读到第一个非空白/非注释行前拒绝加载。常见坑是：
- 文件用了 Windows 换行符（
\r\n），Linux 下可能触发解析失败 - 开头有 UTF-8 BOM（
EF BB BF），MySQL 会把它当非法字符 - 权限不对：MySQL 进程用户（如
mysql）没有读取该文件的权限，尤其当配置文件放在/home/xxx/下时
验证方式：用 sudo -u mysql cat /path/to/my.cnf 看是否能正常输出；用 file /path/to/my.cnf 确认编码和换行格式。
配置写了但 max_connections 或 character_set_server 不生效
这类问题大概率是参数放错了 section。MySQL 只认特定段落下的配置项：
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
-
[mysqld]：服务端参数（如max_connections、innodb_buffer_pool_size）——必须放这里才生效 -
[client]或[mysql]：只影响客户端工具（如mysql命令行），对 mysqld 进程完全无用 -
[mysqld_safe]：仅控制启动包装脚本行为，不传给 mysqld 主进程
一个典型错误是把 max_connections = 2000 写在 [client] 下，重启后查 SHOW VARIABLES LIKE 'max_connections'; 仍是默认值 151。
systemd 管理的 MySQL 忽略 /etc/my.cnf 怎么办？
很多发行版（如 CentOS 8+/Ubuntu 20.04+）的 systemd service 文件里硬编码了 --defaults-file 或通过 EnvironmentFile 指定了另一份配置，导致 /etc/my.cnf 被跳过。
查真实启动命令：systemctl cat mysql 或 ps aux | grep mysqld，重点看有没有 --defaults-file= 或 --defaults-extra-file= 参数。
- 若存在
--defaults-file，优先修改它指向的文件，而不是/etc/my.cnf - 若用
EnvironmentFile=-/etc/sysconfig/mysql，检查该文件里是否有MYSQLD_OPTS="--defaults-file=/xxx.cnf"类似内容 - 修改 systemd 配置后必须运行
sudo systemctl daemon-reload，否则restart不会重新读取 unit 文件
配置文件是否被读、被哪个进程用户读、在哪一个环节被覆盖——这三件事不串起来看，光改 my.cnf 就是白忙。
