先执行SHOW VARIABLES查看日志启用状态及路径，再通过修改配置文件永久开启并重启服务验证；动态开启仅临时有效，需注意权限、路径和磁盘空间问题。
确认 MySQL 日志路径和启用状态
别急着写配置，先看 MySQL 实际在往哪写日志：运行 mysql -u root -p -e "SHOW VARIABLES LIKE 'log_error';" 和 mysql -u root -p -e "SHOW VARIABLES LIKE 'slow_query_log_file';"。如果 slow_query_log 是 OFF，slow_query_log_file 配置再对也没用——得先在 [mysqld] 段加 slow_query_log = ON 并重启，或者执行 SET GLOBAL slow_query_log = ON;（注意部分变量需重启才生效）。
检查路径是否真实存在、权限是否正确：ls -l /var/log/mysql/ 应显示属主是 mysql:mysql；否则 chown mysql:mysql /var/log/mysql，并确保目录可写。
/etc/logrotate.d/mysql 配置必须带 sharedscripts 和 USR1
常见错误是轮转后 MySQL 还往旧文件里写，根本原因是进程没刷新文件句柄。关键不是“移动文件”，而是让 mysqld 关闭旧 fd、打开新文件。
-
sharedscripts必须加：否则多个日志路径会各自触发一次postrotate，而kill -USR1只需发一次 - 用
kill -USR1，不是SIGHUP或mysqladmin flush-logs：前者是 MySQL 官方文档明确用于 reopen error/slow log 的信号；后者虽也能刷日志，但依赖 MySQL 客户端且可能因密码或权限失败 - PID 文件路径要对：
/var/run/mysqld/mysqld.pid是常见路径，但ps aux | grep mysqld才是唯一真相；若实际是/run/mysqld.pid，脚本就静默失效 - 避免通配符如
/var/log/mysql/*.log：万一目录里混了其他服务日志（比如 backup.log），会被一并轮转甚至删掉
binlog 不能走 logrotate，必须交由 MySQL 自控
直接删 mysql-bin.000001 或用 logrotate 清理 binlog，会导致 mysql-bin.index 不一致、主从断裂、恢复失败。这是硬性边界，踩了就出事。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
正确做法是在 [mysqld] 中配置：
-
expire_logs_days = 7（MySQL 5.7–8.0）或binlog_expire_logs_seconds = 604800（MySQL 8.0+） -
max_binlog_size = 100M控制单个文件大小，防止单文件过大 - 清理时用
PURGE BINARY LOGS BEFORE '2026-06-26 00:00:00';或PURGE BINARY LOGS TO 'mysql-bin.000010';
测试必须手动跑一次，不能只靠 cron
配置完不验证，等于没配。两个命令缺一不可：
-
sudo logrotate -d /etc/logrotate.d/mysql：看调试输出里有没有 “rotating pattern”、“running postrotate script”、“killing process” 等关键词 -
sudo logrotate -f /etc/logrotate.d/mysql：强制执行一次，检查/var/log/mysql/下是否出现error.log.1、slow.log.1，再等几秒看 MySQL 是否继续往error.log写新日志（不是 .1）
最容易被忽略的是 create 权限和 SELinux：如果系统启用了 SELinux，create 640 mysql mysql 可能失败，得额外加 semanage fcontext -a -t mysqld_log_t "/var/log/mysql(/.*)?" 并 restorecon -Rv /var/log/mysql。磁盘满之前，它不会报错，只会静默停写。
