最稳定可靠的是 sys.objects，因其统一记录所有数据库对象且 create_date 字段最权威；sys.tables 仅为子集，仅含用户表且 create_date 来自父视图。
SQL Server 中查表创建时间用 sys.tables 还是 sys.objects？
直接查 sys.tables 会漏掉某些系统表或临时对象，真正稳定可靠的是 sys.objects——因为所有数据库对象（包括用户表、视图、存储过程）都统一记录在这里，create_date 字段也最权威。
-
sys.tables是sys.objects的子集，只含类型为'U'（用户表）的行，但它的create_date实际来自父视图，没必要多一层间接 - 必须加
WHERE type = 'U'过滤，否则会混入视图、函数等其他对象 - 注意时区：返回的是服务器本地时间，不是 UTC，跨服务器比对前需确认时区一致性
MySQL 8.0+ 怎么拿到建表时间？INFORMATION_SCHEMA.TABLES 的坑在哪？
INFORMATION_SCHEMA.TABLES 的 CREATE_TIME 字段看似可用，但它在 MySQL 中实际表示「最后一次 DDL 修改时间」，不是初始建表时间。比如执行过 ALTER TABLE ... ADD COLUMN，这个时间就变了。
- 真正可靠的方案是查
performance_schema.table_io_waits_summary_by_table—— 不行，它没存创建时间 - 唯一可行路径：启用并查询
mysql.general_log（如果日志开着且保留了建表语句），或者依赖备份/部署记录 - 5.7 及更早版本完全不记录创建时间，
CREATE_TIME字段值可能为NULL或默认时间（如'0000-00-00 00:00:00'）
PostgreSQL 查 pg_class 为什么得不到创建时间？
PostgreSQL 的系统目录里没有原生的「创建时间」字段。pg_class 存的是表结构元数据，relcreated 这类字段根本不存在。官方明确说明：PG 不跟踪对象创建时间，这是设计取舍。
- 替代思路：查
pg_stat_operations（需开启track_counts = on），它记录 DDL 操作时间，但只保留最近若干条，不可靠 - 生产环境常用办法：在建表时手动插入一条记录到自定义审计表，例如
INSERT INTO audit_table_creation VALUES ('my_table', now(), current_user) - 如果启用了逻辑复制或变更日志（如 Debezium + WAL），可回溯最早的
CREATE TABLE消息时间戳
跨数据库统一查法存在吗？别被 ORM 或 GUI 工具误导
没有通用 SQL 语法能一次性适配所有主流数据库获取建表时间。DBeaver、DataGrip 等工具显示的“创建时间”往往是自己缓存的、或调用数据库特定接口（如 SQL Server 的 sp_help）拼凑出来的，不是标准元数据。
- Django ORM 的
db_table模型属性不包含时间信息；Laravel 的 Schema Builder 也不记录 - 有些工具把文件系统中表对应的数据文件（如 MySQL 的
.frm文件修改时间）当作创建时间——这在启用 InnoDB 共享表空间或云数据库时完全失效 - 真正需要审计级准确性的场景，必须在 DDL 流程中主动注入时间戳，比如通过部署脚本写入
metadata_log表，而不是事后反查
create_date 是 datetime2(3)，毫秒级；PostgreSQL 的 pg_stat_operations 时间戳精度取决于 log_statement 和日志轮转策略；而 MySQL 的 CREATE_TIME 在 FAT32 文件系统上甚至只有 2 秒精度。别拿它们做毫秒级依赖判断。
