字符串存时间会导致隐式转换和索引失效：varchar类型的时间字段在where比较时需逐行解析为时间，破坏b+树有序性，引发全表扫描；改用datetime后可直接走range索引，性能提升数十倍，且支持原生函数、自动校验与时区可控。
字符串存时间会导致隐式转换和索引失效
当你把日期存成 VARCHAR，哪怕写的是 '2026-09-29 10:00:00' 这种标准格式，MySQL 在执行 WHERE create_time > '2026-01-01' 时，仍可能触发隐式类型转换——它得先把字符串逐字符解析成时间才能比较。这个过程无法利用 B+ 树索引的有序性，大概率退化为全表扫描。
- 实测一张千万级订单表，
create_time是VARCHAR(19)，加了索引，但WHERE create_time >= '2026-01-01'的查询仍走type: ALL - 换成
DATETIME后，同样条件直接命中索引，type: range，耗时从 3.2s 降到 47ms - 更隐蔽的坑：用
LIKE '2026%'查询字符串时间，表面能用上索引前缀，但实际是字典序匹配，遇到'2026-13-01'这类非法值也查不出来
DATETIME 支持原生日期函数且自动校验
DATETIME 字段插入 '2026-02-30' 会直接报错 Incorrect datetime value，而字符串字段照单全收，后面查“当月最后一天”或“计算年龄”时才暴露问题。
- 你能直接用
DATE_ADD(create_time, INTERVAL 7 DAY)、TIMESTAMPDIFF(DAY, create_time, NOW())，不用在应用层反复strptime/strftime - 聚合场景如
GROUP BY DATE(create_time)或HAVING MIN(create_time) ，函数下推到存储引擎执行，比应用层处理快一个数量级 - JSON 输出时若需格式化，用
DATE_FORMAT(create_time, '%Y-%m-%d %H:%i')比后端SimpleDateFormat更稳定（避免时区/线程安全问题）
存储空间和可读性之间的真实权衡
有人觉得字符串“看着直观”，但代价是固定多占 11~14 字节（VARCHAR(19) vs DATETIME 的 5~8 字节）。一张千万行的表，光这一个字段就多占近 100MB 存储，还拖慢备份、主从同步、Buffer Pool 加载速度。
-
DATETIME在 MySQL 5.6.4+ 支持微秒精度（DATETIME(6)），需要毫秒级日志也能满足，不必退化到BIGINT - 开发时看表结构，
create_time DATETIME NOT NULL比create_time VARCHAR(19)更能传达业务语义——它明确告诉你：“这是个时间点，别当普通文本处理” - ORM 框架（如 MyBatis、Hibernate）对
DATETIME的映射成熟稳定，而字符串时间常要额外写@JsonFormat或自定义 TypeHandler
为什么不是 TIMESTAMP 或 INT？
选 DATETIME 不是因为它完美，而是它在通用性、范围、可控性上最均衡。如果你的场景有强时区需求（比如全球用户看到本地订单时间），TIMESTAMP 才值得考虑；但它的 2038 年上限在当前系统生命周期里已成硬伤。至于 INT 存秒级时间戳，虽然排序快，但牺牲了所有 MySQL 原生时间能力，连 BETWEEN 都得靠 FROM_UNIXTIME() 包裹，反而增加出错概率。
-
TIMESTAMP的自动时区转换是双刃剑：你改服务器time_zone，历史数据的显示值就变，排查问题时容易误判 -
INT类型字段无法用DEFAULT CURRENT_TIMESTAMP，每次 INSERT 都得显式传值或靠应用层生成 - 现在主流框架默认把
LocalDateTime映射到DATETIME，而Timestamp对象映射到TIMESTAMP，Java 层也要跟着调整
ALGORITHM=INPLACE，也可能锁表数分钟。一开始选对，比后期补救省心十倍。
