information_schema.tables的update_time字段不可靠，对innodb表基本无效，多数返回null或过期值；它反映的是统计更新或表打开时间，而非真实dml时间。
information_schema.tables 的 UPDATE_TIME 字段不能可靠反映表的真实数据更新时间——对 InnoDB 表基本无效，多数返回 NULL 或过期值；它不是“最后 DML 时间”，而是存储引擎统计或元数据刷新的副作用。
为什么 SELECT ... UPDATE_TIME 总是 NULL 或不准
MySQL 官方文档明确说明：UPDATE_TIME 对 InnoDB 表不保证更新。常见现象包括：
-
UPDATE_TIME为NULL（InnoDB 默认行为，尤其未触发ANALYZE TABLE时） - 时间戳停留在建表、优化或上次
FLUSH TABLES时刻，而非你刚执行的UPDATE - 批量导入（如
LOAD DATA INFILE）后该字段完全不变化 - 只读查询、事务回滚、二级索引变更均不会触发其更新
MyISAM 和 InnoDB 的 UPDATE_TIME 行为差异
两者底层机制不同，导致字段语义完全不同：
-
MyISAM：每次INSERT/UPDATE/DELETE后会更新UPDATE_TIME，但受delay_key_write等配置影响，仍可能延迟或丢失 -
InnoDB：该字段仅在满足以下全部条件时才可能非空：innodb_file_per_table=ON+innodb_stats_on_metadata=ON+ 执行了ANALYZE TABLE或表被显式打开（如SHOW TABLE STATUS） - 视图、临时表、分区表、系统表（如
mysql.user）一律不支持UPDATE_TIME
查 .ibd 文件修改时间（仅限本地物理部署）
当确认使用独立表空间（innodb_file_per_table=ON，MySQL 5.6+ 默认开启），且你能登录数据库服务器时，stat 查文件 mtime 是最贴近真实写入的替代方案：
- 先确认路径：
SELECT @@datadir;，再查表对应文件名：SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.tables WHERE ENGINE='InnoDB' AND TABLE_NAME='your_table'; - 在服务器执行：
stat /var/lib/mysql/your_db/your_table.ibd | grep Modify - 注意：
mtime反映的是最近一次刷盘（fsync）时间，不是事务提交时间，但比UPDATE_TIME更有参考价值 - 此法在 RDS、Docker 容器、共享表空间（
innodb_file_per_table=OFF）环境下完全不可用
真正可控的方案：业务层自己维护 updated_at
所有外部手段都是估算，唯一能 100% 控制精度的方式，是在表结构和应用逻辑里主动记录：
- 加字段：
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP - 避免仅依赖触发器：
ON UPDATE CURRENT_TIMESTAMP自动生效，无需额外触发器（除非需兼容旧版本或做审计留痕） - DELETE 操作不自动触发该字段更新，如需追踪删除，必须单独写审计日志或用软删除（
is_deleted+ 更新updated_at） - 高并发写场景下，该字段精度为秒级（MySQL 5.6）或微秒级（5.7+，需定义为
DATETIME(6)）
binlog 并用 mysqlbinlog 解析，也只能看到“哪个表被改了”，但无法直接映射到“哪张业务表”——因为 binlog 记录的是物理行变更，不含库表别名或逻辑上下文。所以，如果没在表里埋 updated_at，后续补救成本远高于初期设计时加一行字段。
