大多数情况下应选 datetime，因其不自动转换时区、范围大（1000–9999年）、支持微秒精度且不受服务器时区影响；timestamp 虽节省存储并自动时区转换，但范围窄（1970–2038）且易因 time_zone 设置导致时间“变化”。
MySQL里存时间，到底该用 DATETIME 还是 TIMESTAMP
大多数情况下，直接选 DATETIME 更省心。它不自动转换时区，范围大（1000–9999年），精度支持到微秒（DATETIME(6)），而且不受服务器时区设置影响。而 TIMESTAMP 虽然节省1字节存储、自动转时区，但范围窄（1970–2038）、受 time_zone 系统变量影响，一不小心插入的时间就“变”了——比如你在 UTC+8 插入 '2024-05-01 12:00:00'，别人在 UTC+0 查，看到的就是 '2024-05-01 04:00:00'。
除非你明确需要跨时区自动同步显示（比如日志系统统一按 UTC 存、前端按用户本地时区渲染），否则别为了“看起来更标准”硬上 TIMESTAMP。
插入时间时，字符串格式写错会导致静默截断或报错
MySQL 对时间字符串格式很敏感，尤其在严格模式下（STRICT_TRANS_TABLES 开启时）。常见错误包括：
- 用斜杠或点分隔：
'2024/05/01 12:30:45'或'2024.05.01 12:30:45'—— 默认不认，会变成'0000-00-00 00:00:00'或直接报错 - 日期部分少于4位年份：
'24-05-01'可能被解释成 2024 或 1924，取决于sql_mode - 时间部分缺零：
'2024-5-1 12:30:5'不合法，必须写成'2024-05-01 12:30:05'
最稳妥的方式是始终用标准 ISO 格式：'YYYY-MM-DD HH:MM:SS'（如 '2024-05-01 12:30:45'），或让应用层用 NOW()、CURRENT_TIMESTAMP 这类函数生成值，避免手拼字符串。
要不要存毫秒？看业务是否真需要
DATETIME 和 TIMESTAMP 都支持小数秒，但得显式声明精度，比如 DATETIME(3) 存毫秒，DATETIME(6) 存微秒。不写括号默认是秒级（等价于 DATETIME(0)）。
多数 Web 业务其实不需要毫秒级精度——订单创建、文章发布时间差几百毫秒根本无感。但如果是高频交易、日志追踪、分布式链路 ID 关联等场景，就得开精度，并注意：
- PHP 的
PDO默认不传毫秒，得手动格式化字符串或启用PDO::ATTR_EMULATE_PREPARES => false - Java 的
java.time.LocalDateTime写入DATETIME(3)没问题，但若字段是DATETIME(0)，JDBC 会四舍五入丢掉毫秒 - 索引效率略降：精度越高，B+树比较越耗时，不过对绝大多数应用可忽略
自动更新时间字段，DEFAULT CURRENT_TIMESTAMP 和 ON UPDATE CURRENT_TIMESTAMP 别混用
想让某字段在插入时自动填当前时间，用 DEFAULT CURRENT_TIMESTAMP；想在更新时自动刷新，加 ON UPDATE CURRENT_TIMESTAMP。但注意：
- 一个表最多只能有一个字段同时用这两个属性（MySQL 5.6.5+ 放宽限制，但多个
TIMESTAMP字段仍受限） -
DATETIME字段用ON UPDATE CURRENT_TIMESTAMP时，必须搭配DEFAULT（哪怕设为DEFAULT NULL），否则建表失败 - 如果字段允许
NULL，且没设DEFAULT，那ON UPDATE不生效 - 更新时只要该行任意字段变化，就会触发
ON UPDATE，不是只在显式 SET 该字段时才动
常见写法示例：
CREATE TABLE event_log (<br> id INT PRIMARY KEY,<br> created_at DATETIME DEFAULT CURRENT_TIMESTAMP,<br> updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP<br>);
这里 created_at 插入时自动填，之后不变；updated_at 插入和每次更新都刷新。别指望靠 ON UPDATE 实现“仅首次更新才改”，那得用触发器或应用层控制。
时区配置、精度选择、自动更新逻辑这三块最容易在线上出问题——尤其是换服务器、迁移数据库、或对接新语言 SDK 时，时间字段常第一个暴露兼容性问题。动手前先查 SELECT @@time_zone, @@sql_mode;，心里有底再建表。
