应使用范围查询替代字符串函数：WHERE create_time >= '2025-08-01 00:00:00' AND create_time

直接用字符串比较时间字段，索引全失效

很多人写 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

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 根本原因：时间戳没对齐时区就做日期切片
• 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？本地时间？有没有自动时区转换？不查清这点，所有比较都像蒙眼射箭。