MySQL 8.0.13+ 可通过 information_schema.TABLES 的 CREATE_TIME 和 UPDATE_TIME 获取表创建与最后DML时间，但 UPDATE_TIME 不响应 DDL；5.7 及更早版本无可靠内置方案。
MySQL 8.0+ 直接查 information_schema.TABLES 是最可靠方式
MySQL 本身不记录表的“创建时间”和“更新时间”到数据字典里，但 8.0.13 及以上版本在 information_schema.TABLES 中新增了 CREATE_TIME 和 UPDATE_TIME 字段，前提是存储引擎支持（InnoDB 表基本都支持，MyISAM 在某些旧版本中可能不准）。
执行以下语句即可获取：
SELECT TABLE_NAME, CREATE_TIME, UPDATE_TIME FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';
注意：UPDATE_TIME 指的是该表最后一次执行 INSERT、UPDATE、DELETE 或 TRUNCATE 的时间，不是 DDL 操作（如 ALTER TABLE）触发的时间 —— 这点容易误解。
-
CREATE_TIME对 InnoDB 表是准确的（从 .frm 文件或数据字典推导而来），但 MySQL 5.7 及更早版本中该字段常为NULL - 如果查询结果中
UPDATE_TIME为NULL，大概率是表从未被修改过，或者使用了不支持该字段的引擎（如 Memory） - 该查询依赖
information_schema的实时性，高并发写入时可能有秒级延迟，不能用于强一致性判断
MySQL 5.7 及更早版本没有 CREATE_TIME 字段，得靠变通方案
5.7 不提供可靠的元数据时间戳，information_schema.TABLES.CREATE_TIME 基本不可用。这时只能结合文件系统和日志来推测：
- 查看表对应的数据文件（如
ibd或MYD）的mtime（修改时间）：它接近建表或最后一次OPTIMIZE时间，但会被ALTER TABLE ... ENGINE=InnoDB等操作覆盖 - 检查
mysql.general_log（如果开启）或 binlog，搜索CREATE TABLE语句的时间 —— 但默认关闭且不保留历史太久 - 部分运维会通过备份脚本或部署系统记录建表时间，这不是数据库原生能力，而是外部管控手段
一句话：5.7 无法从 MySQL 内部准确获取建表时间，别硬查 information_schema 里的空字段。
SHOW CREATE TABLE 不包含时间信息，别指望它返回创建时间
SHOW CREATE TABLE your_table 只输出建表语句和字符集、存储引擎等元信息，完全不带任何时间戳。有人误以为注释或 COMMENT 字段能存时间，但那是人工维护的，MySQL 不自动写入。
-
COMMENT是字符串字段，最大长度 1024 字符，可手动写入时间（如COMMENT='created at 2023-04-01'），但需建表/改表时显式指定 - 一旦忘记加，后续无法反向补全 —— 数据库不会回填
- 这种做法适合小规模项目自管理，不适合自动化运维场景
InnoDB 表的 UPDATE_TIME 不响应 DDL，这是设计使然
很多人发现执行完 ALTER TABLE ADD COLUMN 后，UPDATE_TIME 没变，就怀疑字段失效。其实这是正常行为：UPDATE_TIME 只反映 DML 引起的数据页变更，DDL 属于元数据操作，走的是另一套路径（如 INFORMATION_SCHEMA.INNODB_TABLES 的 LAST_UPDATE_TIME 也不存在）。
- 想监控 DDL 时间？只能查 MySQL 错误日志（
log_error_verbosity = 3时含详细时间）、审计插件，或启用performance_schema的events_statements_history表（需提前开启相关 consumers） -
UPDATE_TIME对应的是innodb_file_per_table=ON下单个表空间的最后写入时间，所以它本质上是个文件系统层面的代理指标，不是事务时间戳
真正要追踪表结构变更，得靠外部工具或日志分析，MySQL 自身没提供开箱即用的“表结构更新时间”字段。
