MySQL数据库如何查看并清理过期日志？

唯一安全清理方式是PURGE BINARY LOGS；确认可删需三步：SHOW BINARY LOGS查已关闭文件、SHOW SLAVE STATUS核对Relay_Master_Log_File确保不删从库未读文件、SELECT检查无活跃Binlog Dump连接。

PURGE BINARY LOGS 是唯一安全的清理方式，直接 rm -f 会导致主从断裂或 MySQL 崩溃。

怎么确认哪些 binlog 真的能删

MySQL 只清理「已关闭」且「未被从库读取」的日志，SHOW BINARY LOGS 输出的文件才可能被删；SHOW MASTER STATUS 返回的 File 字段是当前正在写的日志，它和它之前的文件都不能删。

1. 执行 SHOW BINARY LOGS，检查每行的 File_size：为 0 的文件通常已被关闭，但不等于可删
2. 查从库位置：SHOW SLAVE STATUSG 中的 Relay_Master_Log_File，确保你要删的文件编号或时间点早于它
3. 查是否有活跃 dump 连接：SELECT * FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_COMMAND = 'Binlog Dump'，有就别删

PURGE BINARY LOGS TO 和 BEFORE 到底怎么选

TO 按文件名字典序删（不含目标文件），BEFORE 按事件时间戳删（含等于该时间的所有文件），两者逻辑完全不同，混用会误删。

1. PURGE BINARY LOGS TO 'mysql-bin.000123'：删掉所有字典序小于 mysql-bin.000123 的文件，比如 mysql-bin.000122、mysql-bin.000099 都会被删，但 mysql-bin.000123 保留
2. PURGE BINARY LOGS BEFORE '2024-05-01 00:00:00'：删掉所有第一个事件时间早于该时间戳的文件，哪怕某个日志里只有一条事件在范围内，整个文件也删
3. 注意时区：BEFORE 使用 MySQL 服务器系统时区，不是你本地终端时区 —— 容易差一整天

自动清理为什么没生效

expire_logs_days 在 MySQL 8.0.11+ 已弃用，且它本身不“定时运行”，必须靠 FLUSH LOGS 触发清理逻辑，否则配置再久也没用。

1. 查当前策略：SELECT @@binlog_expire_logs_seconds（推荐）或 SHOW VARIABLES LIKE 'expire_logs_days'
2. 设新值：SET GLOBAL binlog_expire_logs_seconds = 604800（7 天），同时建议 SET GLOBAL expire_logs_days = 0 避免冲突
3. 立即触发清理：FLUSH LOGS —— 它会滚动新 binlog 并清理过期旧文件
4. 生产环境建议加 crontab：0 2 * * * mysql -e "FLUSH LOGS"，每天凌晨跑一次

错误日志和慢查询日志怎么轮转

这类日志不走 MySQL 内部机制，不能用 PURGE，得靠系统工具管理，否则容易堆积失控。

1. 先查路径：SHOW VARIABLES LIKE 'general_log_file'、SHOW VARIABLES LIKE 'slow_query_log_file'
2. 用 logrotate 配置轮转（如 /etc/logrotate.d/mysql）：

   /var/log/mysql/mysql-slow.log {dailyrotate 7missingokcompressdelaycompresspostrotatemysql -e "FLUSH SLOW LOGS;"endscript}

3. 禁用非必要日志更治本：SET GLOBAL slow_query_log = OFF 或 SET GLOBAL general_log = OFF，重启后生效

最容易被忽略的是 GTID 模式下从库未拉取完就 purge，或者 BEFORE 时间写错时区导致多删一天——务必以 SHOW SLAVE STATUS 和 SHOW BINARY LOGS 为准，别信本地 ls 列出的文件名。