查询性能不取决于DATETIME或TIMESTAMP类型，而取决于索引、WHERE条件是否走索引及是否对字段使用函数；时区影响TIMESTAMP显示值但不改变UTC存储值；DATETIME无时区转换但隐含业务时区假设；精度提升增加存储开销；类型选择应基于业务语义——事件时刻用TIMESTAMP，本地约定时间用DATETIME。
查询性能本身不取决于 DATETIME 还是 TIMESTAMP
很多人以为换用 TIMESTAMP 就能提升查询速度，实际不是。两者在 B+ 树索引中的比较逻辑、范围扫描行为、ORDER BY 排序开销几乎一致。真正影响性能的是是否建了索引、WHERE 条件是否能走索引、字段是否被函数包裹（比如 DATE(created_at) 会强制全表扫描）。DATETIME 和 TIMESTAMP 字段只要都加了索引，执行计划里的 key_len 和 type 基本没差别。
时区设置会悄悄改变 TIMESTAMP 查询结果
同一个 TIMESTAMP 字段，在不同 time_zone 下查出来显示值不同，但底层 UTC 值不变。这在跨服务或临时调试时容易引发误判：
- 管理员用
SET time_zone = '+00:00'查日志，看到的是 UTC 时间 - 前端直连数据库用
SET time_zone = '+08:00'，同一行显示为北京时间 - 如果 WHERE 条件写成
WHERE log_time > '2026-05-09 10:00:00'，MySQL 会按当前会话时区把字符串转成 UTC 再比——这意味着你得清楚自己写的字面值对应哪个时区 -
SELECT @@time_zone必须在每次连接后检查，不能默认和服务器全局一致
DATETIME 不自动转换，但也不代表“更安全”
DATETIME 存什么读什么，看似省心，但业务上常隐含时区假设：
- 你插入
'2026-05-09 14:00:00'，它真代表“东八区的 14:00”？还是“UTC 的 14:00”？数据库自己不知道 - 如果应用层没统一时区（比如 PHP 没设
date_default_timezone_set('Asia/Shanghai')），可能插进去就是错的本地时间 - 导出数据给其他系统用时，
DATETIME值没有时区标识，接收方容易误解 - 想用
CONVERT_TZ()转换？DATETIME不支持——它压根不认时区，只能靠应用层硬算
微秒精度和存储空间的实际取舍
带精度的 DATETIME(3) 或 TIMESTAMP(6) 看似精细，但有隐性成本：
-
DATETIME(3)占 8 字节，DATETIME（无精度）只占 5 字节；TIMESTAMP(6)占 7 字节，比基础TIMESTAMP（4 字节）多出 75% 空间 - 高频写入场景（如订单流水、埋点日志），千万级表里每行多 3 字节，总磁盘和缓冲池压力不可忽视
- 除非业务真需要毫秒对齐（比如金融撮合、IoT 传感器同步），否则
DATETIME或TIMESTAMP默认精度完全够用 - 注意：
NOW(3)和CURRENT_TIMESTAMP(6)的精度必须和字段定义一致，否则会静默截断
最常被忽略的一点：类型选型不是纯技术决策，而是业务语义的落地。你存的到底是“某个时刻发生的事件”（用 TIMESTAMP），还是“用户约定的本地时间点”（用 DATETIME）？一旦混淆，后续所有查询、展示、导出都会跟着偏移，而且越到后期越难回溯修正。
