mysql不自动记录备份时间，information_schema无备份日志表；可靠方法依次为：查备份文件修改时间、解析mysqldump日志、查询自建backup_records表。
MySQL 本身不自动记录备份时间，information_schema 里也没有原生的备份日志表——你执行 SELECT * FROM information_schema.tables WHERE table_schema = 'information_schema' AND table_name LIKE '%backup%' 不会返回任何有效结果，因为该库只存元数据（如表结构、列定义），不存运维操作记录。
为什么查不到 backup 相关表？
information_schema 是只读系统视图集合，它不会跟踪备份行为。所谓“含 backup 字样的表”在标准 MySQL 中根本不存在；部分文章提到的查询是误将用户自建表名（比如 backup_records）当作系统表，或混淆了某些云厂商定制版（如 TDSQL-C 的 mysql.backup_history）。
- 标准 MySQL（8.0/5.7）默认无
mysql.backup_history表，该表仅存在于少数托管服务中 -
information_schema.tables的create_time是表本身的创建时间，不是备份时间 - 用
LIKE '%backup%'匹配表名，本质是在找你手动建的表，不是 MySQL 自动维护的
真正能查到上次成功备份时间的三个可靠路径
必须依赖外部机制：人工记录、文件系统时间戳、或日志解析。没有银弹，但有明确优先级：
-
首选：查备份文件的修改时间 —— 如果你用
mysqldump定时写入/backup/mysql/20260408_full.sql，直接运行：ls -lt /backup/mysql/*.sql | head -n1
注意用-t按修改时间倒序，不是-c（状态变更时间）或-u（访问时间） -
次选：查 mysqldump 执行日志 —— 若备份脚本重定向了输出，比如
mysqldump ... > /backup/... 2>> /var/log/mysqldump.log，则：grep -i "completed\|success" /var/log/mysqldump.log | tail -n1
-
可选：查自建记录表（需你提前建好） —— 如已执行过：
CREATE TABLE backup_records (id INT AUTO_INCREMENT PRIMARY KEY, backup_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP);
那么查最新一次就是：SELECT backup_time FROM backup_records ORDER BY backup_time DESC LIMIT 1;
容易被忽略的关键细节
即使你用了自建表，NOW() 或 CURRENT_TIMESTAMP 写入的是语句执行时刻，不代表备份真正完成——如果 mysqldump 进程卡住、磁盘满、或网络中断，这条记录就成“伪成功”。真正可靠的判断必须结合：
- 备份文件实际存在且大小 > 0（
stat -c "%y %s" /backup/xxx.sql） - 备份命令退出码为 0（
$?在 shell 脚本中检查） - 若用
mysqlpump或xtrabackup，其日志结尾明确含"completed successfully"
别指望一个 SQL 查出真相；备份可观测性是运维链路设计问题，不是查询语法问题。
