最常用且稳妥的方式是直接在SELECT中用MIN(time_col)和MAX(time_col)获取时间范围起止；若混选非聚合字段须加GROUP BY，否则报错或结果不可靠；注意时区、数据类型及索引对正确性与性能的影响。
用 MIN 和 MAX 一起查时间范围的起止时间
直接在同一个 SELECT 里用 MIN(time_col) 和 MAX(time_col) 就能拿到最小和最大时间值——这是最常用也最稳妥的方式，不需要子查询或窗口函数。
为什么不能用 GROUP BY 以外的字段混选
如果表里还有其他字段（比如 user_id、status），而你又没加 GROUP BY，MySQL 8.0+ 或 PostgreSQL 会报错：column "xxx" must appear in the GROUP BY clause；老版本 MySQL 可能返回不可靠结果。关键不是语法通不通，而是语义是否明确。
- 只查时间端点：不用
GROUP BY，直接SELECT MIN(ts), MAX(ts) FROM events; - 按用户查各自的时间区间：必须
GROUP BY user_id，否则user_id的值是随机选取的 - 想附带某条“首记录”的完整行（如最早那条的
id）：MIN/MAX不够，得用子查询或ROW_NUMBER()
注意时区与数据类型对结果的影响
MIN 和 MAX 对 TIMESTAMP 和 DATETIME 都有效，但行为不同：
-
TIMESTAMP存储时转为 UTC，读取时按会话时区转换——MIN拿到的是 UTC 下的最小值，显示可能和本地时间不一致 -
DATETIME是纯字面值，不涉及时区转换，更直观 - 如果字段是字符串（如
'2024-03-01 10:30'），且格式不统一（缺前导零、混用横线/斜杠），MIN可能按字典序错判，务必先CAST(col AS DATETIME)再聚合
性能上别踩这些坑
对大表跑 MIN(ts), MAX(ts) 看似简单，但没索引就是全表扫描。
- 确保
ts字段上有单列索引，或者作为联合索引的最左前缀（如INDEX (ts, user_id)） - 如果只查
MIN或只查MAX，优化器常能走索引的最左/最右叶子节点，速度极快；但两者一起查时，某些旧版 MySQL 可能无法复用同一索引路径，建议实测执行计划（EXPLAIN） - 避免在表达式里用函数包裹字段，比如
MIN(DATE(ts))会让索引失效
SELECT MIN(created_at), MAX(created_at) FROM logs WHERE app = 'api';。真正容易出问题的，是后续想基于这个时间范围再关联其他表，或者误以为 MIN 自动带回对应行的其他字段——它不会。 
