GROUP BY 配合 MAX()/MIN() 是统计每组最大最小值最直接可靠的方式，需确保 SELECT 中非聚合字段均出现在 GROUP BY 中，NULL 自动忽略，索引应为（分组字段，聚合字段）以提升性能。
GROUP BY 后直接用 MAX() 和 MIN() 就行
SQL 里统计每组最大最小值，不需要子查询或窗口函数（除非你要保留原始行），MAX() 和 MIN() 配合 GROUP BY 是最直觉也最稳妥的方式。它在所有主流数据库（MySQL、PostgreSQL、SQL Server、SQLite）里行为一致，语义清晰。
常见错误是试图在没 GROUP BY 的情况下混用聚合和非聚合字段，比如：SELECT category, MAX(price), name FROM products; —— 这在严格模式下直接报错，因为 name 没参与分组也没聚合，数据库不知道该取哪一行的 name。
- 必须确保
SELECT中所有非聚合字段都出现在GROUP BY子句中 - 如果想同时拿到最高价那条记录的完整信息（比如商品名、ID），
MAX()本身做不到，得换ROW_NUMBER()或相关技巧 - 空值（
NULL）会被自动忽略——除非整组全是NULL，此时MAX()/MIN()返回NULL
遇到 ONLY_FULL_GROUP_BY 报错怎么办
MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY 模式，一写错就报类似 Expression #2 of SELECT list is not in GROUP BY clause 的错误。这不是 bug，是 SQL 标准在强制你写清楚意图。
别急着关掉这个模式（关了反而埋坑），先检查你的 SELECT 列：哪些是分组键，哪些是聚合结果，哪些是“多余”的。例如：
SELECT dept, MAX(salary), employee_name FROM staff GROUP BY dept;
这里 employee_name 没聚合也没分组，MySQL 拒绝执行。解决方法只有两个：
- 删掉
employee_name（如果你真只需要部门最高薪数值） - 改用聚合函数包裹它，比如
MAX(employee_name)（语义变了，取的是字典序最大名字，不是最高薪那个人）
MAX() 和 MIN() 能用在非数字字段上吗
能，而且很常用。它们按字段类型的自然顺序比较：字符串按字典序，日期按时间先后，布尔值按 FALSE TRUE。
典型场景：查每个用户最新/最早一次登录时间（MAX(login_time) / MIN(login_time)），或每个分类名称字典序最大/最小的商品名（MAX(product_name)）。
- 注意字符集和排序规则（collation）会影响字符串比较结果，比如大小写敏感与否
- 对
TEXT或超长字段，某些数据库（如旧版 MySQL）可能截断后比较，建议测试确认 - 日期类型推荐用
DATE、TIMESTAMP，别用字符串存时间，否则MAX()可能返回字面最大但逻辑错误的结果（比如'2023-12-01'>'2024-01-01'在字符串比较下成立）
性能关键点：索引怎么建才不白忙
MAX()/MIN() 在有合适索引时可以秒出结果，原理是 B+ 树最左/最右叶子节点就是极值。但前提是索引覆盖了 GROUP BY 字段 + 被聚合字段。
比如查每个部门最高薪资：SELECT dept, MAX(salary) FROM staff GROUP BY dept;，最优索引是 (dept, salary)（顺序不能反）。如果只建了 (salary) 或 (dept) 单列索引，数据库大概率要扫全表。
- 复合索引中，分组字段必须在前，聚合字段在后
- 如果还有
WHERE条件，比如WHERE status = 'active'，索引应扩展为(status, dept, salary) - PostgreSQL 支持“仅索引扫描”（Index Only Scan）来加速这类查询；MySQL 8.0+ 的覆盖索引也有类似效果
真正容易被忽略的是：很多人建了索引却没验证执行计划，或者把 MAX(id) 当成“取最新记录”用，而 id 最大 ≠ 时间最新——业务含义和主键设计不一致时，这招会翻车。
