答案是MAX(col)-MIN(col)在GROUP BY后能直接算极差，因其天然适配分组聚合：每组分别计算最大值与最小值再相减，NULL自动忽略，全NULL时结果为NULL，数值类型支持，字符串等不适用。
GROUP BY 后直接用 MAX() - MIN() 就能算极差
极差（最大值减最小值）在分组统计中不需要额外函数或子查询，MAX(字段) - MIN(字段) 在 GROUP BY 语句里天然支持，且结果类型与原字段一致（比如 INT 字段相减仍是 INT）。
常见错误是把极差计算写在 WHERE 或 HAVING 里——这两个子句不能直接引用聚合结果，必须用 SELECT 列别名或重复表达式。
- 正确写法：
SELECT dept, MAX(salary) - MIN(salary) AS range_salary FROM emp GROUP BY dept - 错误写法：
HAVING range_salary > 10000（range_salary是别名，HAVING不识别，得写成HAVING MAX(salary) - MIN(salary) > 10000） - 注意空值：只要组内任一
salary为NULL，MAX()和MIN()会自动忽略它；但若整组全是NULL，结果返回NULL，不是 0
极差为 NULL 时怎么处理
当某组数据全为空值（比如所有 score 都是 NULL），MAX(score) - MIN(score) 返回 NULL，不是 0 或报错。这在报表中常导致“空白”或前端解析失败。
用 COALESCE() 或 ISNULL()（SQL Server）包裹是最直接的兜底方式，但要注意：不能只包一层，因为 MAX() - MIN() 整体为 NULL，需在外层处理。
- 标准写法：
COALESCE(MAX(score) - MIN(score), 0) - 不要写成
COALESCE(MAX(score), 0) - COALESCE(MIN(score), 0)——这会把空值替换成 0，导致极差被严重扭曲（例如实际是NULL, NULL，错误算成0 - 0 = 0） - PostgreSQL/MySQL 8.0+ 支持
NULLS NOT DISTINCT，但对极差无实质帮助，别绕进去
性能和索引影响：MAX/MIN 走索引但 GROUP BY 仍要扫描
MAX() 和 MIN() 在单列上有索引时可以走索引最左匹配（比如 INDEX(dept, salary)），避免排序，但前提是 GROUP BY 字段和聚合字段共同构成索引前缀。
- 高效索引示例：
CREATE INDEX idx_dept_salary ON emp(dept, salary)→ 分组查每组极差快 - 无效索引：
INDEX(salary)单独存在，GROUP BY dept时仍需临时表或文件排序 - 大数据量下，如果只关心极差 > X 的组，加
HAVING MAX(x) - MIN(x) > X不能提前过滤行，只能在聚合后筛组，别指望它减少扫描量
字符串字段也能算“极差”，但逻辑不同
MAX(字段) 和 MIN(字段) 对字符串也合法，按字典序比较，所以 MAX(name) - MIN(name) 在数值类型上下文里会报错（如 MySQL 会尝试隐式转数字失败），而 PostgreSQL 直接拒绝字符串减法。
- 想算字符串长度极差？得先用
LENGTH()或CHAR_LENGTH()提取数值：MAX(LENGTH(name)) - MIN(LENGTH(name)) - 想看首尾字符串差异？别减，用
CONCAT(MIN(name), ' → ', MAX(name))更合理 - 日期字段同理：直接
MAX(ctime) - MIN(ctime)在 MySQL 返回天数差（隐式转为数字），在 PostgreSQL 报错，应显式用MAX(ctime) - MIN(ctime)得 interval，再EXTRACT(DAY FROM ...)
极差看着简单，但空值处理、类型隐式转换、索引依赖这三点，线上出过太多隐蔽问题。尤其当字段允许 NULL 且业务上“无数据”和“数据为 0”有区别时，COALESCE(MAX()-MIN(), 0) 这种写法反而掩盖了真实缺失。
