min/max在全null列返回null而非报错；group by混用非聚合字段会报错；日期字段若为字符串类型，max()将按字典序错误排序。
MIN 和 MAX 返回 NULL 而不是预期值？
当目标列存在 NULL 值时，MIN() 和 MAX() 会自动跳过它们——这本身没错，但如果你的整列都是 NULL，函数就真返回 NULL，而不是报错或提示无数据。常见于左连接后未匹配的字段、条件过滤过严、或字段本身允许空且尚未填充。
实操建议：
- 先用
SELECT COUNT(*) FROM table WHERE column IS NOT NULL确认该列是否有非空值 - 若需兜底（比如没数据时返回 0），用
COALESCE(MIN(column), 0)，但注意：0 可能是合法业务值，慎用 - 聚合前加
WHERE column IS NOT NULL更明确，尤其在调试阶段
在 GROUP BY 中混用 MIN/MAX 和非聚合字段报错
典型错误：SELECT user_id, name, MIN(score) FROM users GROUP BY user_id —— MySQL 5.7+ 和所有标准 SQL 都会报错，因为 name 不在 GROUP BY 列表中，也不被聚合函数包裹。
实操建议：
- 确认语义：你是想查每个
user_id对应的最低分，还是“分数最低那条记录的完整信息”？前者用GROUP BY+MIN()；后者得用窗口函数或子查询 - 若真要取整行（如“每个班级成绩最高者姓名”），改用：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY class ORDER BY score DESC) rn FROM students) t WHERE rn = 1 - MySQL 8.0+ 支持
ANY_VALUE(name)绕过严格模式，但仅限你确定name在组内恒定（如主键关联）
日期字段用 MAX(date) 却拿到错误的“最新”记录
MAX() 对 DATE 或 DATETIME 是有效的，但容易踩两个坑：一是字段类型其实是字符串（如 '2023-1-5'），排序变成字典序；二是时区或精度导致同秒内多条记录，MAX() 只返回一个，但你无法知道它对应哪一行。
实操建议：
- 检查字段类型：
DESCRIBE table_name或SHOW COLUMNS FROM table_name，确保是DATE/DATETIME/TIMESTAMP - 避免字符串存日期：像
'2023/1/5'或'5-Jan-2023'会导致MAX()错误（例如'2023/12/1''2023/2/1'） - 若需“最新一条完整记录”，别只靠
MAX(date)，配合子查询或ORDER BY date DESC LIMIT 1（单条）或窗口函数（多条）
性能差：对大表反复跑 MIN/MAX 很慢
MIN() 和 MAX() 理论上可走索引最左端快速定位，但前提是字段有索引，且没有在表达式里用它（如 MIN(ABS(price)) 就无法用索引）。
实操建议：
- 给常用于
MIN/MAX的字段建单独索引：CREATE INDEX idx_created_at ON orders(created_at) - 复合索引要注意顺序：如果经常查
WHERE status = 'paid' AND MIN(amount)，索引应为(status, amount)，而非反过来 - 避免在函数中包裹字段：
MIN(DATE(created_at))会强制全表扫描，改用MIN(created_at)+ 应用层处理日期部分
极值查询看着简单，但 NULL 处理、语义歧义、类型陷阱和索引依赖这几个点，几乎每次都会卡人一下。特别是把 MAX() 当“取最新一行”用的时候，最容易在数据量变大后暴露逻辑漏洞。
