min函数必须配合group by才能查每组最小值，单独使用仅返回全表最小值；获取完整行需用窗口函数或关联子查询；null值会被忽略，但全null组结果为null；性能依赖联合索引。
MIN函数必须配合GROUP BY才能查每组最小值
单独写 SELECT MIN(price) FROM products 只会返回整张表的全局最小值，不是“每组”。要按分类取最小值，GROUP BY 是硬性前提，缺它就跑不出分组结果。
常见错误是漏掉 GROUP BY 或写错分组字段，比如想按品类找最低价，却写了 GROUP BY id——这会让每行自成一组，MIN() 失去意义。
- 分组字段必须出现在
SELECT列表中（除非用 MySQL 5.7+ 的ONLY_FULL_GROUP_BY关闭模式） - 如果还要显示其他字段（如商品名），不能直接写
SELECT category, MIN(price), name——name不在分组键里，也不被聚合，多数数据库会报错ERROR 1055 - MySQL 8.0+ 支持
MIN() OVER (PARTITION BY category)窗口函数，可避免GROUP BY但需注意结果行数不变
查“每组最小值对应那条完整记录”不能只靠MIN()
MIN(price) 能给出数值，但拿不到同一行的 name 或 id。直接 SELECT category, MIN(price), name 会导致 name 是随机某行的值（MySQL 5.7 默认行为，不可靠）。
真正安全的做法是用子查询或窗口函数：
- 子查询法：先算出每组
MIN(price)，再和原表JOIN匹配category和price两字段（注意多条同价时可能返回多行） - 窗口函数法（推荐）：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY category ORDER BY price) AS rn FROM products) t WHERE rn = 1—— 这能稳定取到每组价格最低的**第一条**记录 - PostgreSQL 可用
DISTINCT ON (category) ORDER BY category, price，更简洁但非标准 SQL
NULL值会让MIN()结果为NULL，不是忽略
MIN() 会自动跳过 NULL 值，但如果某组所有值都是 NULL，结果就是 NULL，不是空或 0。这点容易被忽略，尤其在清洗数据时。
- 检查是否有全空组：
SELECT category, COUNT(*), COUNT(price) FROM products GROUP BY category—— 对比两个计数，差值就是该组NULL个数 - 想把
NULL当 0 处理？用MIN(COALESCE(price, 0))，但逻辑上是否合理得看业务场景 - Oracle 中
MIN()对全NULL组返回NULL；SQL Server、PostgreSQL 行为一致；SQLite 也遵循此规则
性能注意：MIN()在有索引时极快，没索引时要全表扫描
如果常查某字段的分组最小值，给 (group_column, value_column) 建联合索引能极大提升速度，比如 CREATE INDEX idx_cat_price ON products(category, price)。
- 索引顺序很重要：分组字段在前，被聚合字段在后，B+ 树才能高效定位每组首条记录
- 没有索引时，
GROUP BY+MIN()可能触发临时表和文件排序，大数据量下明显变慢 - EXPLAIN 查执行计划时，关注是否有
Using filesort或Using temporary—— 出现就说明索引没生效或缺失
实际写的时候，别只盯着 MIN() 函数本身，分组逻辑、NULL 处理、索引设计、以及“要值还是要整行”这四点卡住多数人。
