应使用范围查询替代字符串函数：WHERE create_time >= '2025-08-01 00:00:00' AND create_time < '2025-09-01 00:00:00'，避免DATE_FORMAT导致索引失效和时间截断问题。
直接用字符串比较时间字段，索引全失效
很多人写 WHERE DATE_FORMAT(create_time, '%Y-%m') = '2025-08' 来查某月数据，结果慢得离谱——因为 DATE_FORMAT 作用在索引列上，MySQL 完全无法走 create_time 的索引，只能全表扫描。
- 真实现象：8月1日 00:00:00 的记录“神秘消失”，不是数据丢了，是字符串比较时隐式类型转换或毫秒截断导致匹配失败
- 正确做法：保持时间字段原始类型，用范围比较：
WHERE create_time >= '2025-08-01 00:00:00' AND create_time - 优势：能命中索引；语义清晰（左闭右开，不漏不重）；兼容 DATETIME/TIMESTAMP 各种精度
边界条件写成“
查“2023-01-01 全天数据”，写成 log_time 看似合理，但遇上带毫秒、微秒的字段（如 <code>DATETIME(6)），或跨时区场景（UTC 存储 + 本地展示），最后一秒可能永远卡在边界外。
- 典型翻车：UTC 时间
2023-01-01 23:59:59.999在北京时间显示为2023-01-02 07:59:59.999，按本地时间筛选就进错分组 - 统一解法：一律用“下一日零点”作为右边界：
log_time >= '2023-01-01' AND log_time - 注意：如果字段是
DATE类型，'2023-01-01'可直接用；若是DATETIME或TIMESTAMP，显式补上00:00:00更稳妥
用 DATE() 截断 UTC 时间做分组，报表总差一天
数据库存的是 UTC，但报表要按北京时间统计。直接写 GROUP BY DATE(created_at)，相当于把 UTC 的 2023-05-01 00:00:00（即北京时间 08:00:00）算作“5月1日”，而 UTC 的 2023-04-30 17:00:00（北京时间 5月1日 01:00:00）却被归到“4月30日”——数据就错位了。
- 根本原因：时间戳没对齐时区就做日期切片
- MySQL 正确写法：
GROUP BY DATE(CONVERT_TZ(created_at, '+00:00', '+08:00')) - SQL Server 对应：
GROUP BY CAST(SWITCHOFFSET(created_at, '+08:00') AS DATE) - 更推荐方案：应用层统一转换后传入目标日期（如
2025-01-23），避免数据库里做时区计算
混淆 CAST 和 CONVERT 的行为差异，SQL Server 比较失准
SQL Server 中，CAST(created_at AS DATE) 和 CONVERT(DATE, created_at) 效果一样，都能去掉时间部分；但若误用 CONVERT(VARCHAR, created_at, 120) 再比较，就退化成字符串比对，受语言设置（如 SET DATEFORMAT mdy）影响，'01/02/2025' 可能被当成 1月2日或2月1日。
- 安全底线：所有比较前先转成明确日期类型，别依赖隐式转换
- 验证字段类型：
EXEC sp_help 'orders'确认order_date是DATETIME还是DATE - 跨库迁移时尤其注意：MySQL 的
DATE()、PostgreSQL 的DATE()、SQL Server 的CAST(... AS DATE)虽然目标一致，但函数名和参数规则完全不同
最麻烦的从来不是语法写不对，而是时间字段到底存的是什么——UTC？本地时间？有没有自动时区转换？不查清这点，所有比较都像蒙眼射箭。
