min(date)和max(date)是计算分组起止日期最轻量可靠的方式，但需注意连续区间识别、时区对齐及null分组陷阱三大问题。
GROUP BY 后直接用 MIN(date) 和 MAX(date) 就行
只要分组逻辑明确，MIN() 和 MAX() 是最轻量、最可靠的方式计算每组的起止日期。数据库对这两个聚合函数做了深度优化，哪怕在千万级表上也基本不触发临时表或文件排序。
常见错误是先 ORDER BY date 再想“取第一行和最后一行”——这不仅写法绕（得用窗口函数或子查询），性能还差一个数量级。
- 确保分组字段和日期字段都有索引，尤其复合索引如
(group_id, date)能让MIN/MAX走索引 B-Tree 的最左/最右叶子节点，O(1) 完成 - 如果日期字段允许
NULL，MIN()/MAX()会自动跳过，不用额外WHERE date IS NOT NULL - PostgreSQL 和 MySQL 8.0+ 支持在
GROUP BY中省略非聚合列（只要它函数依赖于分组键），但别依赖这个，显式写清楚更安全
遇到“日期断开”要分连续区间，不能只靠 MIN/MAX
比如用户登录记录按 user_id 分组，但想算“每次连续活跃的起止时间”，这时 MIN(date) 和 MAX(date) 只会返回整个用户的所有最早和最晚时间，完全没用。
本质是识别“日期是否连续”的问题，必须引入序号差值法（gap-and-island）：
- 用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY date)生成递增序号 - 用
date - INTERVAL ROW_NUMBER() DAY（MySQL）或date - ROW_NUMBER() * INTERVAL '1 day'（PostgreSQL）构造“岛标识” - 再按 user_id 和这个标识
GROUP BY，对每组取MIN(date)和MAX(date)
注意：SQL Server 用 DATEADD(day, -ROW_NUMBER(), date)；SQLite 不支持日期运算，得转为 julian day 整数再减。
时区和精度不一致会导致 MIN/MAX 结果意外偏移
MIN(created_at) 返回的是数据库当前时区下的最小值，不是 UTC，也不是你应用层以为的“本地时间”。如果数据写入时混用了不同时区（比如前端传 ISO 字符串未带 Z，后端又没统一转换），MIN 可能挑出一个逻辑上更早但字面值更大的时间。
- 检查表定义：
created_at是TIMESTAMP WITH TIME ZONE（PostgreSQL）、TIMESTAMP（MySQL，默认系统时区）还是DATETIME（无时区语义） - 写入前强制统一转成 UTC 存储，查的时候再转回本地——别依赖数据库自动时区转换
- 如果字段是
DATETIME类型且含毫秒，MySQL 5.6 默认只存到秒，MIN()看似精确，实际已丢失精度；升级到 5.6.4+ 并声明DATETIME(3)才行
GROUP BY NULL 或空字符串分组时 MIN/MAX 仍有效，但语义易错
当分组字段全为 NULL（比如 GROUP BY CASE WHEN status = 'active' THEN user_id END，部分行匹配失败），整张表会被当成“一组”，MIN(date) 就变成全表最小日期——不是 bug，是 SQL 标准行为。
- 用
COUNT(*)对照验证：如果某组COUNT(*)异常大，大概率是分组键为NULL导致合并了不该合的数据 - 加
HAVING COUNT(*) > 1000快速暴露这种隐性分组塌缩 - 避免用表达式直接做分组键，优先在
WHERE里过滤掉NULL情况，或用COALESCE(group_key, 'unknown')显式归类
连续区间识别、时区对齐、NULL 分组陷阱——这三个地方不细看执行计划和样本数据，很容易上线后才发现结果不对。
