MIN() 配合 GROUP BY 才能按分类取最早时间；单独使用只返回全表最小值。必须指定分组字段（如 category），且 SELECT 中非聚合字段须在 GROUP BY 中出现，否则报错；时间戳需为 TIMESTAMP/DATETIME 类型并注意时区与精度。
MIN() 配合 GROUP BY 才能按分类取最早时间
单独用 MIN(timestamp) 只会返回整张表的最小值，不是每个分类下的最早时间。必须搭配 GROUP BY 指定分类字段（比如 category、user_id 或 status），才能让数据库对每组分别计算最小值。
常见错误是漏写 GROUP BY，或者把非分组字段直接塞进 SELECT 里导致报错（如 MySQL 8.0+ 严格模式下会提示 Expression #1 of SELECT list is not in GROUP BY clause）。
实操建议：
- 确认分类字段名拼写正确，且该字段允许为
NULL——MIN()会自动跳过NULL值，但如果整组全是NULL，结果就是NULL - 如果分类字段有索引，
GROUP BY+MIN()通常能走索引扫描，性能较好；否则可能触发全表排序 - 时间戳字段类型应为
TIMESTAMP、DATETIME或带时区的TIMESTAMPTZ，避免用字符串存时间（否则MIN()比较的是字典序，不是真实时间顺序）
处理多字段关联时，别直接在 MIN() 外层套其他字段
想查“每个分类下最早时间戳对应的完整记录”（比如那条记录的 id 或 detail），不能这么写：SELECT category, MIN(timestamp), id FROM logs GROUP BY category —— id 不在 GROUP BY 里，也不被聚合函数包裹，多数数据库会直接报错。
正确做法是先用子查询或窗口函数定位目标行：
- MySQL 8.0+/PostgreSQL：用
ROW_NUMBER() OVER (PARTITION BY category ORDER BY timestamp)标记每组最早行为1，再外层过滤 - 兼容老版本：用
JOIN关联原表和分组结果，条件是t1.category = t2.category AND t1.timestamp = t2.min_ts，但要注意时间戳重复时可能返回多行 - 如果只要单个附加字段且不介意任意一行，部分数据库支持
ANY_VALUE(id)（MySQL）或first_value(id) OVER (...)（PostgreSQL），但语义上不保证是同一行
注意时区和精度对 MIN(timestamp) 结果的影响
MIN() 比较的是存储值本身。如果时间戳字段是 TIMESTAMP 类型（MySQL 默认带时区转换），而写入时没统一时区，不同记录的实际 UTC 时间可能错乱，导致 “最早” 结果不符合业务预期。
另外，毫秒级精度需留意：
- MySQL 的
TIMESTAMP默认只存到秒，即使列定义为TIMESTAMP(3)，也要确认插入时显式传了毫秒（如'2024-05-20 10:00:00.123'） - PostgreSQL 的
TIMESTAMP WITH TIME ZONE默认支持微秒，但客户端驱动或 ORM 可能截断精度 - 用
EXTRACT(EPOCH FROM timestamp)转成数值再比大小，可规避部分精度隐式转换问题，但一般没必要
WHERE 条件必须放在 GROUP BY 之前过滤，不能放 HAVING 里
想查 “状态为 active 的每个用户最早登录时间”，WHERE status = 'active' 必须写在 GROUP BY 前面。如果误写成 HAVING status = 'active'，会报错 —— HAVING 只能引用分组字段或聚合结果（如 MIN(timestamp)），不能引用原始行字段。
另一个典型陷阱是时间范围过滤写错位置：
- ✅ 正确：
WHERE created_at >= '2024-01-01' GROUP BY user_id—— 先筛数据再分组 - ❌ 错误：
GROUP BY user_id HAVING MIN(created_at) >= '2024-01-01'—— 这查的是“最早时间在 2024 年之后的用户”，逻辑完全不同 - 如果既要限制原始数据时间范围，又要对结果二次筛选（比如只看最早时间在某区间内的分类），才需要组合
WHERE+HAVING
最易被忽略的是时间字段是否真的包含你需要的全部时间点——比如日志表里有些记录的 timestamp 是 NULL 或默认值 '0000-00-00 00:00:00'，它们会被 MIN() 当作有效值参与比较，结果可能远早于业务实际起始时间。
