推荐在 DEFAULT 和 ON UPDATE 子句中统一使用 CURRENT_TIMESTAMP，因其符合 SQL 标准、兼容性更好、可被优化器识别为常量；NOW() 虽功能相似但语义弱且旧版本支持差。
MySQL 日期函数选 NOW() 还是 CURRENT_TIMESTAMP？
两者在大多数场景下行为一致，但语义和 隐式类型转换 有差异。NOW() 返回 DATETIME 类型，CURRENT_TIMESTAMP 是 SQL 标准函数，可被优化器识别为常量（尤其在分区表或生成列中）。如果建表时用 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP，后续插入不显式赋值会自动填充；而用 NOW() 作默认值虽可行，但部分旧版本 MySQL 会报错或触发警告。
- 推荐在
DEFAULT和ON UPDATE子句中统一用CURRENT_TIMESTAMP，兼容性更好 -
NOW(3)支持毫秒精度，CURRENT_TIMESTAMP(6)可到微秒，但需字段定义匹配（如TIMESTAMP(6)） - 在 WHERE 条件里直接写
WHERE created_at > NOW() - INTERVAL 1 DAY没问题，但若字段是DATE类型，应改用CURDATE()避免 隐式转换
用 DATE()、DATE_FORMAT() 还是直接比较？
对 DATETIME 字段查“今天的数据”，别写 WHERE DATE(created_at) = CURDATE() —— 这会让索引失效。MySQL 无法对函数结果使用 B+ 树索引，DATE() 强制全表扫描。
- 正确写法：
WHERE created_at >= CURDATE() AND created_at -
DATE_FORMAT(created_at, '%Y-%m')适合展示，不适合查询条件；它返回字符串，无法走索引 - 若频繁按年月查询，考虑添加生成列：
ALTER TABLE logs ADD COLUMN ym CHAR(7) STORED GENERATED ALWAYS AS (DATE_FORMAT(created_at, '%Y-%m'))，再给ym加索引
TIMESTAMP 和 DATETIME 字段选哪个？
不是只看“要不要时区转换”。TIMESTAMP 占 4 字节，范围是 1970-01-01 00:00:01 到 2038-01-19 03:14:07；DATETIME 占 8 字节，范围大得多（1000 到 9999 年），且存值不随系统时区变化。
- 业务时间线明确在 2038 年前、且需自动转时区（如日志记录 UTC 时间但 前端 显示本地时间），用
TIMESTAMP - 存储生日、合同到期日、历史归档时间等固定时刻，必须用
DATETIME，否则跨时区读取会出错 - 注意：
TIMESTAMP默认开启explicit_defaults_for_timestamp后行为更可控；老版本未设该参数时，第一个TIMESTAMP列可能被自动设为CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
批量更新时间字段 为什么 越来越慢？
常见于定时任务执行 UPDATE orders SET updated_at = NOW() WHERE status = 'pending'，随着数据量增长，哪怕有 status 索引，也可能因回表、锁竞争、二级索引维护开销变慢。
- 加
updated_at到联合索引末尾，例如INDEX idx_status_updated (status, updated_at)，让覆盖扫描成为可能 - 避免在高并发更新场景中依赖
NOW()—— 它每次调用都触发一次系统调用，不如用应用层传入统一时间戳（如UPDATE …… SET updated_at = ?） - 若只是标记“已处理”，考虑用无符号整型
processed_at INT UNSIGNED存 Unix 时间戳，减少类型转换与索引体积
时区设置、字段类型选择、函数是否可索引——这三处不注意，性能问题往往在数据量上万后才暴露，但修复成本远高于设计阶段就定好规则。
