最可靠方式是用 find -mtime（非-ctime）按修改时间删除旧MySQL备份文件，因-mtime反映实际写入完成时间；需配合-type f、-name精确过滤，先-print测试再-delete，并在crontab中设置PATH和错误日志。

用 find 按修改时间删旧备份文件最可靠

Linux 下清理 MySQL 备份，find 是最轻量、最可控的选择。它不依赖数据库状态，也不需要额外服务，直接操作文件系统即可。关键不是“能不能删”，而是“按什么时间维度删”——必须用 -mtime（修改时间）而非 -ctime（状态变更时间），因为备份脚本通常只改文件内容，不改权限或属主，-ctime 容易误判。

• -mtime +7 表示“7天前及更早修改的文件”，注意：不是“超过7天”，是“>= 7*24小时”，跨午夜计算，别按日历天数理解
• 备份文件名带日期（如 backup_20240501.sql.gz）时，find 仍应优先看 -mtime，因为重命名、解压、传输都可能改变 -ctime 或 -atime，唯独 -mtime 反映实际写入完成时间
• 务必先加 -print 测试，例如：find /backup/mysql -name "*.sql.gz" -mtime +7 -print，确认列出的确实是目标文件再加 -delete

MySQL 备份路径里混着临时文件？用 -type f 和 -name 组合过滤

生产环境的备份目录常有 .tmp、.part、锁文件或日志，直接 find ... -delete 可能误删正在写的备份。安全做法是显式限定文件类型和命名模式。

• 只删普通文件：find /backup/mysql -type f，排除目录、socket、设备节点
• 限定扩展名组合：-name "*.sql.gz" -o -name "*.xbstream" -o -name "*.zst"，避免匹配到 mysql-bin.000001 这类二进制日志（它们该由 expire_logs_days 管）
• 如果备份脚本生成临时文件（如 backup_20240501.sql.gz.part），加 ! -name "*.part" 排除，否则 -mtime +7 可能把未完成的也删了

保留最近 N 个备份？find 本身不支持“按数量留档”，得配合 sort 和 tail

按天备份但要求“永远留最近 14 个”，仅靠 -mtime 不行——某天没备份，+14 就会多删；某天双备份，+14 又会少删。必须按文件名或时间戳排序后取尾部。

• 假设文件名含 ISO 日期：find /backup/mysql -name "*.sql.gz" -printf "%T@ %p\n" | sort -n | head -n -14 | cut -d' ' -f2- | xargs -r rm（按修改时间戳排序，留最后 14 个）
• 如果文件名更规范（如 backup_20240501_0200.sql.gz），用 ls -t | tail -n +15 | xargs rm 更直观，但要注意 ls -t 依赖 mtime，且目录下不能有非备份文件干扰
• 别用 stat 替代 -printf：stat 调用开销大，在万级文件时明显变慢；find -printf 是单次遍历，效率高一倍以上

放进 crontab 前必须加 PATH 和错误重定向

crontab 默认 PATH 极简（通常只有 /usr/bin:/bin），找不到 find 或 gzip 就静默失败；不重定向错误，删错文件也无从察觉。

• 在 crontab 条目开头显式声明：PATH=/usr/local/bin:/usr/bin:/bin
• 命令末尾加 2>> /var/log/clean_mysql_backup.log，把 stderr 记下来，特别是 rm: cannot remove 或 find: cannot read 这类权限错误
• 加 set -e 和 set -u 到 shell 包裹脚本里，避免变量为空导致 find /backup//*.gz 这种路径错误被忽略

真正难的不是写对那条 find 命令，是搞清你的备份流程里哪些时间点可信、哪些文件名模式稳定、以及 crontab 环境和交互式终端差在哪。删之前多跑两遍 -print，比事后翻备份恢复日志省十倍力气。