答案是MAX(col)-MIN(col)在GROUP BY后能直接算极差，因其天然适配分组聚合：每组分别计算最大值与最小值再相减，NULL自动忽略，全NULL时结果为NULL，数值类型支持，字符串等不适用。
为什么 MAX(col) - MIN(col) 在 GROUP BY 后能直接算极差
极差 = 最大值 - 最小值，而 MAX() 和 MIN() 是聚合函数，天然适配 GROUP BY 场景。只要分组逻辑正确，两者在同一组内计算出的值相减，结果就是该组的极差。
注意：不能在未分组或分组字段缺失时直接用，否则会退化为全表极差；也不能对非数值列（如字符串、日期）盲目套用——虽然某些数据库允许对日期做 MAX() - MIN()（返回天数差），但对字符串这么做通常无意义且结果不可控。
-
MAX()和MIN()会自动忽略NULL值，若某组所有值都是NULL，结果为NULL，相减后仍是NULL - 如果列含负数，极差仍为正数（例如
MAX(-1, -5) = -1，MIN(-1, -5) = -5，差值为4） - 浮点列需留意精度问题，比如
DECIMAL(10,2)更稳妥，FLOAT可能导致极差出现微小误差
写法示例：按 category 分组求 price 极差
假设有一张商品表 products，含字段 category（分类）、price（价格），需求是每类价格波动范围：
SELECT category, MAX(price) - MIN(price) AS range_price FROM products GROUP BY category;
这个查询简洁有效，但有几点实操细节要注意：
- 若想保留小数位，可用
ROUND(MAX(price) - MIN(price), 2)，避免浮点显示过长 - 若
price是TEXT类型（比如存了“¥99”），必须先清洗转成数值，否则MAX()按字符串比较（“100” - PostgreSQL 中若列名含大小写或特殊字符，记得用双引号包裹，如
MAX("Price") - MIN("Price")
遇到 NULL 或空组时怎么处理
当某组数据全为 NULL，或根本没数据（外连接后可能出现），MAX() - MIN() 返回 NULL，这本身合理，但业务上有时需要默认值（如 0）。
此时用 COALESCE() 最直接：
SELECT category, COALESCE(MAX(price) - MIN(price), 0) AS range_price FROM products GROUP BY category;
但注意：COALESCE(MAX(price), 0) - COALESCE(MIN(price), 0) 是错误写法——它把缺失最大值/最小值分别补 0，会导致极差失真（比如实际只有 [5] 一组，MAX=5、MIN=NULL，错误写法得 5-0=5，看似对；但若只有 [NULL, NULL]，就变成 0-0=0，掩盖了无数据事实）。
- 始终对整个表达式用
COALESCE(..., default)，而不是分别包裹MAX和MIN - MySQL 8.0+ 支持
IFNULL()，效果同COALESCE(expr, 0)，但仅限两个参数 - 若需区分“有数据但极差为 0”和“无数据”，就不能填默认值，得靠外层判断
COUNT(*)是否为 0
性能与索引是否影响极差计算
单纯 MAX()/MIN() 在有合适索引时可以走索引最左前缀快速定位，不扫全表。比如对 (category, price) 建复合索引，GROUP BY category 后求 MAX(price)/MIN(price) 就可能只查每个 category 对应的首尾索引项。
但现实里容易被忽略的是：一旦加上 WHERE 过滤（如 WHERE status = 'active'），优化器是否还能高效利用索引，取决于过滤条件选择率和索引顺序。
- 推荐索引：优先建
(category, status, price)而非(category, price)，把高频过滤字段放在中间 - 执行计划中看到
Using filesort或Using temporary，大概率没走索引优化，极差计算会变慢 - SQL Server 中可考虑用窗口函数替代（如
MAX(price) OVER (PARTITION BY category)），但需配合DISTINCT去重，反而更重，不推荐用于纯极差场景
极差本身计算开销极小，瓶颈永远在数据扫描和分组过程；别指望靠改写表达式提速，重点检查索引覆盖和 WHERE 条件写法。
