VARCHAR类型日期字段用MIN()按字典序比较不可靠，可能返回非法值如'2023-13-01'；WHERE中不能直接用聚合函数，需子查询或窗口函数；注意NULL值导致条件恒假；应先查DISTINCT值验数据质量。
日期字段是 VARCHAR 类型但内容像日期，MIN() 会“看似正常”实则不可靠
常见现象是 SELECT MIN(created_at) FROM logs 返回了某个值，但和业务时间对不上——比如返回了 '2023-13-01' 或 '2023-01-00' 这类非法字符串。这是因为 VARCHAR 字段的 MIN() 按字典序比较，'2023-01-00' '2023-01-01' '2023-01-10'，但它根本不是有效日期。
必须确认字段类型：DESCRIBE logs 或 SHOW COLUMNS FROM logs LIKE 'created_at'。如果类型是 VARCHAR、TEXT 或 CHAR，哪怕内容全是 '2023-01-01' 格式，MIN() 也只做字符串比较，不校验合法性，更不按时间语义排序。
- 修复方式：用
STR_TO_DATE(created_at, '%Y-%m-%d')（MySQL）或TO_DATE(created_at, 'YYYY-MM-DD')（PostgreSQL）先转成日期再聚合 - 长期方案：ALTER TABLE 修改字段类型为
DATETIME或TIMESTAMP，并加CHECK (created_at ~ '^\d{4}-\d{2}-\d{2}(\s\d{2}:\d{2}:\d{2})?$')（PostgreSQL）约束非法值写入 - 临时验证：运行
SELECT created_at FROM logs WHERE created_at !~ '^\d{4}-\d{2}-\d{2}(\s\d{2}:\d{2}:\d{2})?$'（PostgreSQL）或SELECT created_at FROM logs WHERE STR_TO_DATE(created_at, '%Y-%m-%d') IS NULL（MySQL）查出脏数据
字段是 DATETIME/TIMESTAMP 但精度丢失导致 MIN() 结果偏移
MySQL 5.6.4 之前，DATETIME 默认只存到秒级，毫秒部分被截断；即使你插入 '2023-01-01 10:00:00.123'，存储后只剩 '2023-01-01 10:00:00'。MIN() 看似返回了“最早时间”，实际可能漏掉同一秒内更早的记录。
检查方式：SHOW CREATE TABLE logs 看字段定义是否带精度，如 DATETIME(3) 表示毫秒级；若无括号，则大概率是秒级。
- 升级后建表应显式声明精度：
created_at DATETIME(3) NOT NULL - 已有表需
ALTER TABLE logs MODIFY created_at DATETIME(3)（MySQL），注意该操作会锁表 - PostgreSQL 的
TIMESTAMP WITH TIME ZONE默认支持微秒，但也要确认应用层写入时没主动截断
时区混用让 MIN(created_at) 返回“逻辑上更晚”的时间
现象：数据库显示 MIN(created_at) 是 '2023-01-01 08:00:00'，但业务日志里第一条记录实际发生在 UTC 时间 '2023-01-01 00:00:00'。这是因为字段是 TIMESTAMP（MySQL）或 TIMESTAMP WITHOUT TIME ZONE（PostgreSQL），而写入时前端传的是本地时间字符串（如 '2023-01-01T08:00:00+08:00'），后端未统一转成 UTC 就直接入库。
MIN() 计算的是字面值最小，不是真实世界时间轴上最早。
- 根本解法：所有写入前强制转成 UTC，字段类型用
TIMESTAMP WITH TIME ZONE（PostgreSQL）或TIMESTAMP（MySQL，配合time_zone='+00:00'） - 查询时再按需转换：
SELECT MIN(created_at AT TIME ZONE 'Asia/Shanghai') FROM logs（PostgreSQL） - 避免依赖数据库自动时区转换——MySQL 的
CONVERT_TZ()在聚合中性能差，且容易因会话变量不一致出错
WHERE 中误用 MIN() 导致语法错误
典型错误语句：SELECT * FROM events WHERE created_at > MIN(created_at)，报错 Invalid use of group function。这不是日期格式问题，而是 SQL 执行顺序决定的：WHERE 在分组和聚合前执行，此时 MIN() 还没计算。
想查“非最早那条记录”，必须把聚合结果作为常量参与比较：
- 子查询方式：
SELECT * FROM events WHERE created_at > (SELECT MIN(created_at) FROM events) - 窗口函数更清晰（推荐）：
SELECT * FROM (SELECT *, MIN(created_at) OVER() AS min_time FROM events) t WHERE created_at > min_time - 注意空值：如果
created_at允许为 NULL，MIN()会忽略它；但子查询若全为 NULL，结果是 NULL，整个 WHERE 条件变成created_at > NULL→ 永远为 FALSE
真正卡住人的往往不是函数不会用，而是日期字段表面看着“能比”，背后藏着类型、精度、时区、NULL 四重陷阱。跑通 MIN() 前，先用 SELECT DISTINCT created_at FROM ... LIMIT 5 看原始值长什么样，比直接调函数更有用。
