SHOW VARIABLES 查询结果才是配置是否生效的最终答案；它反映实际加载值，需结合配置文件路径核查、mysqld --validate-config 静态校验、重启后日志检查三步交叉验证。
直接查 SHOW VARIABLES 得到的值，才是配置是否“正确”的最终答案——它不看你写了什么，只看你改的有没有被真正加载并生效。
查运行时值：用 SHOW VARIABLES 看真实生效值
这是验证配置是否起效的第一步，也是唯一可信的依据。文件里写得再对，没进内存就等于没写。
-
SHOW VARIABLES LIKE 'max_connections';—— 查单个参数，通配符%必须写，比如'%buffer%' -
SELECT @@global.innodb_buffer_pool_size;—— 返回纯数字，适合脚本解析 -
SELECT @@session.sql_mode;—— 会话级参数只影响当前连接，SHOW VARIABLES默认显示会话值，容易误判全局配置 - 别依赖
cat /etc/my.cnf或编辑器里的内容，它可能根本没被 MySQL 加载（比如你改了~/.my.cnf，但服务是以mysql用户跑的）
定位配置来源：确认 MySQL 到底读了哪个文件
MySQL 启动时按固定顺序扫描多个路径，后读到的同名参数会覆盖前面的。你改的文件，未必是它读的那个。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 执行
mysql --help | grep "Default options"，看搜索路径列表（常见：/etc/my.cnf → /etc/mysql/my.cnf → ~/.my.cnf） - 执行
mysqld --verbose --help | grep "Default options"，这是服务端实际使用的路径 - MySQL 8.0.22+ 可直接查：
SELECT @@global.config_file;，返回主配置文件绝对路径 - 如果启动命令里带了
--defaults-file=/path/to/my.cnf，那其他所有路径都会被忽略，只读这一个
校验配置语法和兼容性：不重启也能发现错误
改完配置别急着重启，先用 mysqld --validate-config 做静态检查。它能立刻报出拼写错误、单位错误、废弃参数等，比等服务崩了再翻日志快得多。
- 基本校验：
mysqld --defaults-file=/etc/my.cnf --validate-config - 查弃用警告（如
slave_preserve_commit_order）：mysqld --defaults-file=/etc/my.cnf --validate-config --log-error-verbosity=2 - 注意版本匹配：用 MySQL 8.0.31 的
mysqld去验 8.0.29 的配置文件，可能漏掉旧版特有参数或误报新特性 - 这个命令不启动服务，也不加载数据目录，纯文本解析，安全可靠
重启后必须交叉验证三件事
改的是静态参数（比如 port、datadir、innodb_buffer_pool_size），就必须重启。但重启不是终点，只是起点。
- 重启后立刻连上去跑一次
SHOW VARIABLES LIKE 'xxx';，确认值变了 - 查错误日志路径：
SELECT @@global.log_error;，然后tail -n 20 /var/log/mysql/error.log，找unknown variable或option ignored这类关键词 - 检查进程启动参数：
ps aux | grep mysqld，确认没被命令行参数覆盖（比如--max-connections=500会压过配置文件里的设置） - 动态参数（如
max_connections）可用SET GLOBAL临时改，但仅当前有效——别把它当持久化手段
最容易被跳过的环节是错误日志检查。很多配置“看起来生效了”，但日志里早写了 [Warning] option 'innodb_log_file_size' has different value，说明实际加载的是默认值而非你写的值。不看日志，等于没验。
