MySQL配置未生效主因是改错文件路径或被高优先级配置覆盖，需用mysqld --verbose --help查加载顺序、ps aux看是否指定--defaults-file、docker inspect确认挂载，再检查语法、section位置、动态/静态参数区别及系统限制。
配置文件写了，mysqld 也重启了，但 SHOW VARIABLES 里还是旧值——这基本不是“没生效”，而是你改的那行压根没被 MySQL 看见。
确认 MySQL 实际加载了哪个配置文件
MySQL 不会自动读你随手保存的 my.cnf，它只按固定顺序扫描几个路径，后读的覆盖先读的。你改的文件可能根本不在这个列表里，或者被更高优先级的文件盖掉了。
- 运行
mysqld --verbose --help | grep "Default options"，看输出的第一行路径（比如/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf），这就是它真正检查的顺序 - 用
ps aux | grep mysqld查进程启动命令，如果带了--defaults-file=xxx，那它只认这个文件，其他全忽略 - Docker 容器里尤其要查：
docker inspect 容器名看Volumes和Mounts，宿主机文件没挂载进去，改了等于白改
检查配置语法和 section 位置是否合法
MySQL 对配置格式很敏感，错一个字符就跳过整行，甚至整个 section。它不会报错，只是静默忽略。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
-
[mysqld]必须独占一行，前后不能有空格或注释；写成[mysqld ]或# [mysqld]都无效 - 参数必须形如
innodb_buffer_pool_size = 2G：等号两边可有空格，但不能用冒号、不能省略等号、不能加引号（log_error = "/var/log/mysqld.log"反而可能失败） - 中文标点（如全角等号、冒号）会导致整段解析失败，日志里常报
unknown variable或直接不加载 - 用
mysqld --validate-config验证语法；失败时会明确指出第几行出错
区分动态参数和静态参数的生效方式
有些参数改了配置文件也得重启，有些则必须靠 SET GLOBAL，还有些压根不支持运行时修改——混用就会以为“没生效”。
- 像
max_connections、wait_timeout这类是动态参数，可SET GLOBAL立即生效，但不写进配置文件的话，重启就丢 - 像
innodb_log_file_size、datadir是静态参数，必须改配置 + 重启，SET会报错Variable 'xxx' is a read only variable - 像
sql_mode比较特殊：配置文件里设了只影响新连接，已存在的连接仍用旧值；且必须放在[mysqld]下，写在[client]里完全无效
注意系统级限制和版本兼容性
参数值再正确，也可能被 OS 或 MySQL 版本拦下来。这时 SHOW VARIABLES 显示的不是你写的值，而是降级后的默认值，但日志里未必提示。
-
open_files_limit：如果系统ulimit -n是 1024，你配了 65535，MySQL 会静默用 1024，SHOW VARIABLES里显示的就是 1024 -
innodb_buffer_pool_size：设成超过物理内存，MySQL 启动可能直接崩溃，或启动后立刻被 OS OOM kill - 升级到 MySQL 8.0 后，
query_cache_type已移除，继续写在配置里会导致启动失败；character-set-server在 5.7.22+ 默认不生效，必须搭配collation-server
最常被忽略的是：你以为自己在改全局配置，其实编辑的是用户级 ~/.my.cnf；或者 Docker 里挂载了 /etc/mysql/conf.d/，但真正起作用的是 /etc/mysql/mysql.conf.d/mysqld.cnf ——路径差一级，效果就归零。
