必须用SHOW VARIABLES LIKE 'log_error';查真实路径，因该值动态反映MySQL当前写入日志的绝对路径，不受配置文件加载状态、默认路径猜测或发行版差异影响，是唯一精准可靠的方式。
直接查 log_error 变量最准
只要 MySQL 服务能连上，就别猜路径、翻文档或查配置文件——执行 SHOW VARIABLES LIKE 'log_error';，返回的 Value 字段就是当前正在写入的错误日志绝对路径。这个值是运行时真实生效的路径，不受配置文件是否加载、路径是否被覆盖、发行版差异影响。
常见返回示例：/var/log/mysqld.log（CentOS）、/var/log/mysql/error.log（Ubuntu）、/usr/local/mysql/data/localhost.err（源码安装）。
注意：log_error 不是 log-error（后者只在配置文件中有效，SQL 里用错会查不到）；大小写敏感，拼错就为空。
log_error 返回空或 NULL 怎么办
这不是“找不到”，而是 MySQL 根本没启用错误日志。此时它会退回到默认行为：把日志写进 datadir 目录下，文件名是主机名加 .err 后缀（如 myserver.err）。
- 先执行
SHOW VARIABLES LIKE 'datadir';拿到数据目录路径 - 然后进该目录运行
ls -lh *.err查看是否存在匹配主机名的.err文件 - 若仍无结果，检查是否被 systemd journal 接管：运行
sudo journalctl -u mysqld -n 50 --no-pager
返回空还可能因为配置文件有语法错误导致变量未加载，或 my.cnf 放错了段落（比如写在 [client] 里而非 [mysqld]）。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
连不上 MySQL 时只能翻配置文件
服务崩了、启动失败、根本连不进客户端？那就没法执行 SQL，只能靠配置文件定位。
重点不是“找 my.cnf”，而是确认它是否被实际加载：
- Linux 常见位置：
/etc/my.cnf、/etc/mysql/my.cnf、/etc/mysql/conf.d/*.cnf - Windows 一般在：
C:\ProgramData\MySQL\MySQL Server X.X\my.ini（ProgramData是隐藏目录） - 必须在
[mysqld]段落下找log_error = /path/to/error.log，其他段落无效 - 路径写相对值（如
log_error = mysql-error.log）时，实际位置要结合datadir解析
不确定配置文件加载顺序？运行 mysqld --help --verbose | grep "Default options" 看实际扫描路径。
路径对但读不了日志？权限和 SELinux 是真拦路虎
即使 SHOW VARIABLES LIKE 'log_error'; 返回了路径，tail -f /var/log/mysql/error.log 报 Permission denied，大概率不是少输 sudo，而是下面某个环节断了：
- 文件属主不是
mysql用户，或权限不是640或600（比如chmod 640 /var/log/mysql/error.log） - SELinux 启用且上下文不对（RHEL/CentOS 常见）：用
sudo ls -Z /var/log/mysql/看是否为mysqld_log_t，不是就修复：sudo semanage fcontext -a -t mysqld_log_t "/var/log/mysql(/.*)?"，再restorecon -Rv /var/ - logrotate 配置了日志轮转但没重载权限，旧日志文件可能残留为 root 所有
真正容易被忽略的是：Docker 容器里挂载的日志路径，宿主机上看到的属主和权限，跟容器内 MySQL 进程视角可能不一致——得进容器里 ls -l 确认。
