用 DATETIME 或 TIMESTAMP 存日期，别用 VARCHAR；DATETIME 范围大、无时区转换，适合固定时间点；TIMESTAMP 范围小、自动时区转换，适合跨时区场景；建表应设 DEFAULT CURRENT_TIMESTAMP；CURRENT_DATE/CURDATE 返回 DATE 类型日期，NOW 返回 DATETIME/TIMESTAMP 类型完整时间戳，CURTIME 返回 TIME 类型时间；按天聚合用 DATE(date_col)，按月用 YEAR*100+MONTH；WHERE 中避免对日期字段用函数以防全表扫描。
MySQL 日期字段怎么存才不会出问题
用 DATETIME 或 TIMESTAMP 存日期，别用 VARCHAR。后者看着灵活，实际查起来慢、排序错、没法用索引，连 BETWEEN 都可能漏数据。
-
DATETIME范围大（1001–9999），不自动时区转换，适合记录固定时间点（如订单创建时间） -
TIMESTAMP范围小（1970–2038），写入时自动转为 UTC，查询时转回当前会话时区，适合需要跨时区统一管理的场景 - 建表时加默认值：
created_at DATETIME DEFAULT CURRENT_TIMESTAMP，避免应用层拼字符串出错
CURRENT_DATE、NOW、CURDATE 有什么区别
三个都返回当前日期/时间，但精度和类型不同，混用容易在比较或计算中出隐式转换问题。
-
CURRENT_DATE→ 只返回日期部分，类型是DATE，等价于CURDATE() -
NOW()→ 返回完整时间戳（年月日时分秒），类型是DATETIME（或TIMESTAMP，取决于上下文） -
CURTIME()→ 只返回时间部分（时:分:秒），类型是TIME - 注意：
NOW()在同一个 SQL 语句里多次调用返回相同值；而SYSDATE()每次调用都实时取系统时间
怎么按天/月/年做统计（GROUP BY 常见坑）
直接 GROUP BY date_col 看似简单，但如果字段是 DATETIME 类型，会按“精确到秒”分组，导致同一天的数据被拆开。
- 按天聚合：用
DATE(date_col)或DATE_FORMAT(date_col, '%Y-%m-%d')，前者更高效 - 按月聚合：用
YEAR(date_col) * 100 + MONTH(date_col)（生成 202405 这种整数），比DATE_FORMAT(date_col, '%Y-%m')更利于索引下推 - 避免在
WHERE里对日期字段用函数，比如WHERE DATE(created_at) = '2024-05-01'会导致全表扫描；应改写为：WHERE created_at >= '2024-05-01' AND created_at
日期加减和间隔计算怎么写才安全
别手算天数再拼字符串，MySQL 提供了专门函数处理时序逻辑，否则跨月、闰年、时区都会出错。
- 加减日期：
DATE_ADD(NOW(), INTERVAL 7 DAY)、DATE_SUB(NOW(), INTERVAL 1 MONTH)——INTERVAL后单位必须是关键词（DAY、WEEK、MONTH等），不能写成字符串 - 计算间隔：
DATEDIFF('2024-05-10', '2024-05-01')返回整数天数；TIMESTAMPDIFF(DAY, start_time, end_time)更灵活，支持SECOND/MINUTE/MONTH等单位 - 注意：
ADDDATE()和DATE_ADD()功能一致，但前者不支持SECOND级别，建议统一用DATE_ADD()
日期操作真正难的不是语法，而是时区设置、字段类型选择、以及 WHERE 条件里是否无意触发了函数索引失效——这些地方一错，查出来的结果可能看起来对，但上线跑几天就发现数据对不上。
