expire_logs_days未生效是因为它仅在binlog切换或MySQL重启时触发清理，非实时定时任务；需配合FLUSH LOGS手动触发，并确保log_bin启用、用户有RELOAD权限。
expire_logs_days 设置后为什么日志没被清理？
MySQL 的 expire_logs_days 是个“软开关”：它只在每次 binlog 切换（比如执行 FLUSH LOGS）或 MySQL 重启时触发一次清理检查，不是后台常驻定时任务。所以即使你设了 expire_logs_days = 7，如果实例长期不切换日志、也不重启，旧 binlog 就会一直堆积。
常见错误现象：SHOW BINARY LOGS 显示大量超期文件；磁盘空间持续增长；mysql-bin.000001 等文件时间戳远早于 7 天前。
- 必须确保
log_bin已启用（否则该参数无效） - 确认当前用户有
RELOAD权限（否则FLUSH LOGS会失败） - 检查 MySQL 错误日志中是否有类似
Failed to delete old binary log file的报错，通常是权限或文件被其他进程占用
如何安全地在线设置 expire_logs_days
直接改配置文件再重启最稳妥，但生产环境常需在线调整。推荐分两步走：
- 先用
SET GLOBAL expire_logs_days = 7生效（仅对后续切换生效，不影响当前已存在的日志） - 立即执行
FLUSH LOGS触发一次清理 —— 这会新建一个 binlog 文件，并顺带删除所有超过 7 天的旧文件 - 再把
expire_logs_days = 7写入my.cnf的[mysqld]段，避免重启后失效
注意：SET GLOBAL 设置在实例重启后丢失，纯临时行为；而写入配置文件是持久化动作，两者缺一不可。
比 expire_logs_days 更可靠的替代方案
MySQL 5.7.5+ 支持更精确的 binlog_expire_logs_seconds（秒级控制），优先级高于 expire_logs_days。若你依赖小时级清理（比如保留最近 48 小时），直接用这个：
SET GLOBAL binlog_expire_logs_seconds = 172800;
同时写入配置文件：
[mysqld] binlog_expire_logs_seconds = 172800
优势在于：精度更高、无需依赖日志切换频率、且与系统时间严格对齐。老版本只能靠脚本补位 —— 比如每天用 cron 调用 mysql -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);"。
清理失败时怎么手动干预？
当自动机制卡住，又不能随便重启时，用 PURGE BINARY LOGS 手动删是最直接的方式，但必须小心：
- 先查清楚哪些从库还在用：
SHOW SLAVE STATUS\G看Relay_Master_Log_File，确保不删掉从库还没读完的 binlog - 用
SHOW BINARY LOGS列出所有文件及创建时间，人工核对 - 执行
PURGE BINARY LOGS TO 'mysql-bin.000010'（删到指定文件名之前）或PURGE BINARY LOGS BEFORE '2024-05-01 00:00:00' - 禁止用
rm直接删文件 —— MySQL 不会更新内部索引，下次FLUSH LOGS可能报错或跳过后续文件
真正容易被忽略的是主从延迟场景：哪怕设置了 7 天，如果某个从库延迟了 10 天，PURGE 删掉的 binlog 可能让它彻底断复制。务必先确认所有从库 Seconds_Behind_Master 接近 0，或至少 Read_Master_Log_Pos 未落在待删范围内。
