DBeaver 中显示的表“最后修改时间”不可靠：MySQL 的 UPDATE_TIME 常为 NULL 或清空，PostgreSQL 无原生支持，其“Last modified”仅为本地缓存刷新时间；真实数据更新时间需依赖业务字段（如 updated_at）或数据库审计日志。
MySQL 表的最后修改时间在 DBeaver 里查不到
DBeaver 本身不存储、也不主动读取 MySQL 表的“最后修改时间”——MySQL 的 INFORMATION_SCHEMA.TABLES 中的 UPDATE_TIME 字段理论上记录了表最后一次 DML（INSERT/UPDATE/DELETE）时间，但实际中它经常为 NULL 或不准，尤其在使用 InnoDB 引擎且未开启 innodb_file_per_table，或表被 TRUNCATE、OPTIMIZE 后会清空该值。DBeaver 的“元数据”视图（右键表 → View Table Info）显示的 Update time 就是这个字段，别当真。
PostgreSQL 没有原生表级最后修改时间字段
PostgreSQL 根本不提供类似 MySQL 的 UPDATE_TIME。系统表 pg_class 的 reltuples 和 relpages 只反映统计信息，pg_stat_all_tables 中的 last_vacuum/last_analyze 是维护时间，不是数据变更时间。DBeaver 在 PostgreSQL 连接下看到的“Last modified”列纯属界面占位或缓存时间（比如你上次刷新元数据的时间），和表内容无关。
真正能查到“最后更新时间”的方案只有两种
如果你必须知道某张表最近一次被写入的时间，只能靠以下方式之一，且都需提前设计或额外权限：
- 在业务逻辑中写入时间戳：给表加一个
updated_at字段，配合ON UPDATE CURRENT_TIMESTAMP（MySQL）或触发器/默认值（PostgreSQL），然后查SELECT MAX(updated_at) FROM table_name - 启用数据库审计日志（如 MySQL 的 general_log 或 binlog，PostgreSQL 的
log_statement = 'mod'），再解析日志定位最后 DML 时间——但这对性能影响大，且 DBeaver 不直接支持解析，得用命令行或外部工具 - 注意：
pg_stat_all_tables.last_data_changed是社区补丁或某些云厂商（如 AWS RDS PostgreSQL）私有扩展，并非标准 PostgreSQL 功能，DBeaver 不识别该字段
DBeaver 里误以为“修改时间”准确的常见错觉
很多人右键表 → Properties 或打开 Metadata 标签页，看到 “Modified”、“Updated” 这类字段就以为是数据变更时间，其实那是：
- MySQL：来自
INFORMATION_SCHEMA.TABLES.UPDATE_TIME，不可靠 - PostgreSQL：DBeaver 自己记录的本地元数据缓存刷新时间（比如你 10 分钟前点过 Refresh）
- Oracle / SQL Server：可能对应
LAST_DDL_TIME（结构变更时间，不是数据变更） - 所有情况：不会随 INSERT/UPDATE 自动更新，也不会实时同步
想靠 DBeaver 点几下就拿到真实数据更新时间，这条路走不通。得从建表时就考虑审计字段，或者接受“数据库本身不记录这个信息”这个事实。
