直接用 MAX() 和 MIN() 函数即可，但需注意 NULL 会被自动跳过、必须配合 GROUP BY 使用非聚合列、索引对性能至关重要，且字符串/日期比较受排序规则和时区影响。
直接用 MAX() 和 MIN() 函数就行，但要注意 NULL 和分组场景
这两个聚合函数本身极快，MySQL、PostgreSQL、SQL Server 都在索引列上做了优化。但如果目标列有大量 NULL，MAX() 和 MIN() 会自动跳过它们——这不是 bug，是标准行为。常见错误是误以为结果为空就代表数据缺失，其实可能是全为 NULL。
使用场景上，单表查极值最简单；但若需同时查多列极值（比如「销售额最高那条记录的客户名和日期」），不能只靠 MAX(sales)，得配合子查询或窗口函数，否则会拿错关联字段。
- 确保列上有索引，尤其是大表；无索引时全表扫描不可避免
- 如果列定义为
NOT NULL，优化器更容易利用索引的最左/最右叶节点快速定位极值 - 在
WHERE条件已过滤出小结果集时，先WHERE再MAX/MIN比反过来快得多
别在 SELECT 里混用聚合和非聚合列，除非加 GROUP BY
写 SELECT name, MAX(price) FROM products 会报错（MySQL 5.7+ 严格模式、PostgreSQL、SQL Server 均如此），因为 name 没参与聚合，数据库不知道该取哪一行的 name。这是初学者高频报错点，错误信息通常是 "column must appear in the GROUP BY clause" 或类似提示。
正确做法只有两种：要么只选聚合结果，如 SELECT MAX(price), MIN(price) FROM products；要么明确分组，如 SELECT category, MAX(price), MIN(price) FROM products GROUP BY category。
- 想查「每个类别的最高价商品完整信息」？
GROUP BY不够，得用ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC) - MySQL 8.0+ 支持
SELECT ... FROM t WHERE price = (SELECT MAX(price) FROM t)，但注意可能返回多行（并列最高）
MAX() / MIN() 对字符串和日期也有效，但逻辑取决于排序规则
对 CHAR、VARCHAR 列，MAX(name) 返回字典序最大的字符串（例如 'Zebra' > 'apple'，如果排序规则是 case-sensitive）；对 DATE 或 TIMESTAMP，就是时间最晚/最早的那个值——这点很直观，但容易被忽略的是时区影响：PostgreSQL 默认按 UTC 存储 TIMESTAMP WITH TIME ZONE，而 MySQL 的 TIMESTAMP 会随会话时区转换，MIN(created_at) 结果可能因连接参数不同而变化。
- 字符串比较受数据库 collation 控制，
utf8mb4_0900_as_cs区分大小写和重音，utf8mb4_general_ci则不区分 - 避免对表达式用
MAX()，如MAX(UPPER(name))—— 无法走索引，且语义模糊 - 日期范围查询优先用
WHERE date_col BETWEEN '2023-01-01' AND '2023-12-31'，而不是靠MIN()/MAX()反推区间
性能差？先看执行计划，再检查是否真需要实时计算
如果 SELECT MAX(id) FROM huge_table 很慢，不是函数问题，而是没索引或索引失效。InnoDB 的主键是聚簇索引，查 MAX(primary_key) 通常只需访问 B+ 树最右叶子节点，毫秒级；但查非主键列的极值，必须依赖该列上的二级索引，否则就是全表扫描。
更隐蔽的问题是：业务是否真的需要每次查询都算一遍？比如「当前最大订单号」用于生成新单号，频繁查 MAX(id) + 1 容易引发并发冲突，不如用自增主键或序列。
- 用
EXPLAIN SELECT MAX(col)看key是否命中索引，rows是否接近 1 - PostgreSQL 可建表达式索引：
CREATE INDEX idx_max_on_status ON t ((status = 'active'))，配合MAX(CASE WHEN status='active' THEN created_at END) - 对超大表，考虑物化视图（PG）或汇总表（MySQL），把极值缓存成一行，定期刷新
