UPPER 和 UCASE 在绝大多数情况下功能等价，但 UPPER 是 SQL 标准函数，兼容性更广；UCASE 仅为 MySQL 别名，在 PostgreSQL、SQL Server 等中不支持。
UPPER 和 UCASE 在主流数据库中是否等价
绝大多数情况下，
和
功能完全一致，都用于将字符串转为大写。但兼容性差异明显：
是 SQL 标准函数，支持 PostgreSQL、SQL Server、Oracle、SQLite、MySQL 8.0+；
是 MySQL 专属别名（早期版本仅支持它），在 PostgreSQL 或 SQL Server 中直接使用会报错
。
实操建议：
跨数据库项目或不确定目标环境时，统一用
纯 MySQL 5.7 及更早版本可任选，但建议仍用
以利后续升级
PostgreSQL 用户若误写
，会收到明确错误提示，需立刻替换为
UPPER 函数对 NULL 和非字符串值的处理
接收任意类型表达式，但实际只对文本生效；遇到
直接返回
，不会报错；若传入数字（如
），多数数据库（如 PostgreSQL、SQL Server）会隐式转成字符串再转换，结果是
（不变）；MySQL 则可能触发警告或静默转为字符串。
常见陷阱：
字段本身为
时，
结果仍是
，做
会漏掉空值行，但通常这不是问题——除非你显式想包含空值逻辑
不要对整数列盲目套用
，既无意义又可能掩盖类型误用（比如本该查
却写了
）
若字段是
（PostgreSQL）或
（MySQL），
会失败或返回异常结果，必须先用
/
转为文本
在 WHERE 和 ORDER BY 中使用 UPPER 的性能影响
在
条件中写
，会导致索引失效（除非你建了函数索引）；在
中，排序开销随数据量线性上升，因为每行都要计算一次。
优化方式：
MySQL/PostgreSQL 支持函数索引：例如
，之后
就能走索引
更常见的做法是业务层保证写入时统一大小写（如全存小写），查询时直接用
，避免运行时转换
若必须不区分大小写查询，PostgreSQL 可用
，MySQL 可用
（注意 collation 区分大小写）替代函数调用
中文、emoji 和特殊字符能否用 UPPER 正常处理
只对 ASCII 字母（a–z）有效；中文、日文、emoji、带重音符号的拉丁字母（如 é, ñ）均不受影响，原样返回。例如
还是
，
得到
（不是
）。
这意味着：
别指望
解决多语言首字母大写需求（如 ‘zhāng sān’ → ‘Zhāng Sān’），它做不到
某些数据库（如 PostgreSQL）提供扩展函数如
处理首字母大写，但也不支持中文
真正需要国际化大小写转换的应用（如用户显示名格式化），应交由应用层语言（Python 的
、JavaScript 的
）处理，它们支持 Unicode 大小写规则
实际用的时候，最容易被忽略的是函数索引的存在感——很多人写了
查询慢，第一反应是换写法，而不是检查有没有配对应的函数索引。
UPPERUCASEUPPERUCASEfunction ucase does not existUPPERUPPERUCASE('abc')UPPER('abc')UPPERNULLNULLUPPER(123)'123'NULLUPPER(column_name)NULLWHERE UPPER(name) = 'JOHN'UPPERidUPPER(id)BYTEABLOBUPPERCONVERTENCODEWHEREUPPER(name) = 'ALICE'ORDER BY UPPER(name)CREATE INDEX idx_upper_name ON users (UPPER(name))WHERE UPPER(name) = 'ALICE'name = 'alice'ILIKECOLLATE utf8mb4_0900_as_csUPPERUPPER('你好')'你好'UPPER('café')'café''CAFÉ'UPPERinitcap()str.title()toLocaleUpperCase()UPPER(col)