最可靠方式是运行mysqld --help --verbose | grep "default options"，输出的路径顺序中第一个存在且权限合法（如644）的my.cnf即为实际加载文件；debian/ubuntu常用/etc/mysql/my.cnf并可能通过!include覆盖参数，docker内需进容器确认路径，改前须备份、停服务、用--validate-config校验语法。
怎么确认 MySQL 实际加载的是哪个 my.cnf
硬改 /etc/my.cnf 却没效果，大概率是 MySQL 根本没读它。Linux 下 MySQL 启动时只认第一个存在的配置文件，顺序固定：/etc/my.cnf → /etc/mysql/my.cnf → $MYSQL_HOME/my.cnf → ~/.my.cnf，后面全被跳过。
最可靠的方法是运行：
mysqld --help --verbose | grep "Default options"
输出中带 my.cnf 的那行就是真实搜索路径。Debian/Ubuntu 系统通常用 /etc/mysql/my.cnf，而且该文件里常含 !include /etc/mysql/conf.d/*.cnf ——你改的参数可能被 conf.d 里的某个文件覆盖。
进 Docker 容器后别猜路径，先执行 ls /etc/mysql/ 或 ls /etc/ | grep my.cnf 确认存在性。
innodb_buffer_pool_size 放错 section 就等于没写
MySQL 只在对应程序段里读参数，其他地方全当注释处理。写错 section 是配置不生效的头号原因。
-
[mysqld]：所有服务端参数必须放这里，比如innodb_buffer_pool_size、max_connections、bind_address -
[client]：只影响mysql、mysqldump等客户端工具，比如default-character-set=utf8mb4 -
[mysql]：仅作用于mysql命令行客户端，比如pager less -S
常见错误：innodb_log_file_size = 2G 写在 [client] 下完全无效；user=root 写在 [mysqld] 会导致 mysqld 以 root 身份启动，属于严重安全风险。
改完必须验证语法再重启，否则可能起不来
直接改完就 systemctl restart mysql，很容易因拼写错误或参数不兼容导致服务无法启动，尤其在生产环境。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
改之前务必做三件事：
- 备份原文件：
cp /etc/mysql/my.cnf /etc/mysql/my.cnf.bak - 停掉 mysqld：
systemctl stop mysql（Ubuntu）或systemctl stop mysqld（RHEL/CentOS 8+） - 验证语法：
mysqld --defaults-file=/etc/mysql/my.cnf --validate-config，返回空才表示通过；报错如unknown variable 'innodb_buffer_pool_size'，说明版本太老或参数名写错（例如极老版本只认innodb_buffer_pool）
注意单位写法：innodb_buffer_pool_size = 2G 合法，但 sort_buffer_size = 2M 在高并发下设太大反而拖慢性能。
重启后查 SHOW VARIABLES，别信配置文件里的值
配置文件写对了 ≠ MySQL 运行时真用了那个值。有些参数动态可调（如 max_connections），但多数需重启才生效，且可能被子配置或命令行参数覆盖。
重启后立刻验证：
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
如果返回值还是旧的，说明要么没重启成功，要么参数根本没加载——这时要回看错误日志：tail -n 20 /var/log/mysql/error.log，常见报错包括权限问题（如文件 world-writable）、路径不存在、或 !include 指向的目录里有语法错误文件。
最后提醒一句：阿里云 RDS、腾讯云 CDB、Docker 官方镜像等托管场景，my.cnf 不可直接修改。那些是只读文件，重启即丢，得走控制台参数模板或 API 调整。
