greatest/least遇null即返null，源于sql三值逻辑；需用coalesce或case预处理null；pg/mysql原生支持但oracle/sql server不支持；慎用于where/order by以防索引失效。
为什么GREATEST/LEAST不能直接处理NULL值
当任意参数为 NULL 时，GREATEST 和 LEAST 会整体返回 NULL，哪怕其余列全是有效数字。这不是bug，而是SQL三值逻辑的体现——比较操作中一旦涉及 NULL，结果即为未知（UNKNOWN），函数据此放弃推导。
常见错误现象：GREATEST(col_a, col_b, col_c) 在某行 col_b IS NULL 时整行结果变 NULL，而非取 col_a 和 col_c 中较大者。
- 解决思路：用
COALESCE或CASE预先将NULL转为极值占位符 - 若求最大值，把
NULL替换为一个足够小的数（如-999999999）；若求最小值，则替换为极大数（如999999999） - 更安全的做法是用
CASE显式排除NULL，但表达式会变长
PostgreSQL与MySQL对GREATEST/LEAST的兼容性差异
GREATEST 和 LEAST 在 PostgreSQL 和 MySQL 中原生支持，但 Oracle、SQL Server 不支持——Oracle需用 DECODE + 多层 CASE 模拟，SQL Server 则得靠 VALUES 构造行集再配合 MAX/MIN。
使用场景：跨数据库迁移脚本时，该函数是典型“隐性不兼容点”。例如以下语句在 MySQL/PG 可跑，在 SQL Server 直接报错：
SELECT GREATEST(a, b, c) AS max_val FROM t;
- PostgreSQL 允许混合类型（如
GREATEST(1, '2'::text)），但会隐式转为公共类型，易引发意外截断或转换错误 - MySQL 8.0+ 要求所有参数类型兼容，否则报
ER_INVALID_TYPE_FOR_OPERATION - 参数个数无硬性上限，但超 20 个列时性能下降明显（尤其在大表
SELECT中）
替代方案：用UNION ALL + GROUP BY模拟多列极值
当目标数据库不支持 GREATEST/LEAST，或列数动态变化（如来自JSON展开）、或需同时获取极值所在列名时，用 UNION ALL 拆行再聚合更可控。
示例：从三列 score_math、score_eng、score_phy 中取每行最高分及对应科目：
SELECT id,
MAX(score) AS max_score,
(ARRAY['math', 'eng', 'phy'])[MIN(CASE WHEN score = MAX(score) OVER(PARTITION BY id) THEN rn END)] AS subject
FROM (
SELECT id, score_math AS score, 1 AS rn FROM t
UNION ALL
SELECT id, score_eng, 2 FROM t
UNION ALL
SELECT id, score_phy, 3 FROM t
) AS u
GROUP BY id;
- 此法明确规避了
NULL传播问题——UNION ALL后可加WHERE score IS NOT NULL - 适合需要关联原始列上下文（如字段别名、单位、时间戳）的场景
- 缺点是数据量翻倍（N列→N倍行数），大表慎用
性能陷阱：GREATEST/LEAST在WHERE和ORDER BY中的误用
在 WHERE 子句里写 WHERE GREATEST(a,b,c) > 100 看似简洁，但多数数据库无法对该表达式有效走索引——优化器通常将其视为黑盒计算，导致全表扫描。
同样，ORDER BY GREATEST(x,y,z) 会强制每行都计算一次，且无法利用已有索引排序。
- 若列上有单列索引，应改写为等价布尔组合：
WHERE a > 100 OR b > 100 OR c > 100 - 如需稳定排序，考虑提前计算并持久化到生成列（MySQL 5.7+/PG 12+ 支持）：
ALTER TABLE t ADD COLUMN max_score INT GENERATED ALWAYS AS (GREATEST(a,b,c)) STORED - 注意：生成列上建索引后，
WHERE max_score > 100才真正可优化
GREATEST 得立刻 EXPLAIN 看是否走了索引，而不是只验证结果对不对。
