MySQL 的 GREATEST 函数可直接比较多列值，返回单行内最大值，但任一参数为 NULL 则结果为 NULL，且要求参数类型兼容；PostgreSQL 也支持该函数（8.1+），SQL Server 和 Oracle 不支持或限制多参数，跨库应优先用 CASE WHEN。
MySQL 的 GREATEST 函数能直接比较多列值
GREATEST 是 MySQL 原生支持的函数，可传入两个或更多表达式（列、常量、计算结果），返回其中最大值。它不适用于 NULL 值较多的场景——只要任一参数为 NULL，整个结果就是 NULL。
常见误用是把它当“忽略 NULL 取最大”的工具，实际并非如此。例如：GREATEST(col1, col2, col3) 在 col2 IS NULL 时直接返回 NULL，不会跳过它去比 col1 和 col3。
- 所有参数类型需兼容，否则触发隐式转换（如字符串和数字混用可能出意外）
- 推荐显式用
COALESCE处理空值：例如GREATEST(COALESCE(col1, -9999), COALESCE(col2, -9999)) - PostgreSQL、SQL Server、Oracle 不支持
GREATEST；想跨库兼容，得改用CASE WHEN或UNION ALL + ORDER BY + LIMIT 1
PostgreSQL 中没有 GREATEST，但可用 LEAST/GREATEST 的替代写法
PostgreSQL 其实也支持 GREATEST 和 LEAST，从 8.1 版本起就已存在，且行为与 MySQL 高度一致。很多人误以为它不支持，是因为早期文档不醒目，或测试时用了含 NULL 的数据没注意返回值。
真正要注意的是类型推断：如果传入不同数据类型（比如 GREATEST('2', 10)），PostgreSQL 会尝试统一类型，失败则报错 ERROR: COALESCE types text and integer cannot be matched。
- 确保所有参数类型相同，或显式转成同一类型：
GREATEST(col1::numeric, col2::numeric) - 对日期列有效：
GREATEST(updated_at, created_at)返回较新的时间 - 不能用于聚合场景（如
GROUP BY后对每组取各列最大值），那是MAX()的职责
SQL Server 和 Oracle 用户别硬套 GREATEST，改用 CASE WHEN 更可靠
SQL Server 完全不提供 GREATEST；Oracle 虽有，但只支持最多 2 个参数（12c 以前），且对 NULL 处理逻辑略有差异。此时最通用、最可控的方式是手写 CASE WHEN 链。
比如三列取最大：col1, col2, col3，可写成：
CASE WHEN col1 >= COALESCE(col2, col1) AND col1 >= COALESCE(col3, col1) THEN col1 WHEN col2 >= COALESCE(col1, col2) AND col2 >= COALESCE(col3, col2) THEN col2 ELSE COALESCE(col3, col1) END
这个写法明确控制了 NULL 的处理逻辑（用 COALESCE 替换为参照值），也避免了类型隐式转换风险。
- 列数越多，
CASE越长，建议封装为计算列或视图避免重复 - 若性能敏感（如大表高频查询），考虑在应用层做比较，而非让数据库反复解析复杂
CASE - Oracle 用户可用
GREATER自定义函数，但需 DBA 权限，上线成本高
用 GREATEST 比 MAX() 快？别被名字骗了，它们根本不是一回事
GREATEST 是行内横向比较（row-wise），作用于单行内的多个值；MAX() 是纵向聚合（column-wise），扫描整列后返回一个标量。两者语法位置、执行阶段、优化路径完全不同，不存在“谁更快”的比较基础。
典型错误是试图用 GREATEST(MAX(a), MAX(b)) 去求两列各自最大值中的更大者——这其实等价于 SELECT GREATEST( (SELECT MAX(a) FROM t), (SELECT MAX(b) FROM t) )，要跑两次子查询，还无法利用索引合并。
- 真要横向取多列最大值，就用
GREATEST（MySQL/PG）或CASE（SQL Server） - 真要纵向聚合取列最大值，就用
MAX(col)，别掺和GREATEST - 混合需求（如“每行取 a/b/c 最大值，再对这些最大值求平均”）必须分步：先
GREATEST生成临时列，再AVG()聚合
GREATEST 当作“万能最大值函数”，而忽略了它对 NULL 的零容忍、对类型一致性的强要求，以及不同数据库的实际支持差异。上线前务必在目标环境的真实数据上验证含空值、边界值、混合类型的 case。 
