UPPER()函数将字符串转为大写，适用于报表输出、数据清洗和模糊匹配前的标准化；不修改原数据，NULL输入返回NULL；需注意嵌套顺序、数据库差异及索引失效问题。
UPPER函数的基本用法和适用场景
直接用 UPPER() 就能转大小写，它接受一个字符串表达式（列名、字面量或拼接结果），返回全大写的副本。常见于报表输出、数据清洗、模糊匹配前的标准化处理。
比如查用户姓名统一展示为大写：
SELECT UPPER(name) AS name_upper FROM users;
注意：它不修改原表数据，只影响查询结果；对 NULL 值返回 NULL，不会报错。
嵌套使用和常见错误组合
实际中常和 CONCAT()、TRIM() 或字段拼接一起用，但顺序错了会出问题——比如先拼接再转大写，比先转再拼接更安全。
-
UPPER(CONCAT(first_name, ' ', last_name))✅ 正确：先拼再转 -
CONCAT(UPPER(first_name), ' ', UPPER(last_name))⚠️ 语义不同：每个字段单独转，空格仍是小写 -
UPPER('hello' || NULL)→NULL：任何含 NULL 的字符串操作在多数数据库里都得小心
不同数据库对UPPER的支持差异
MySQL、PostgreSQL、SQL Server、Oracle 都支持 UPPER()，但行为有细微差别：
- PostgreSQL 默认区分大小写，
UPPER('café')返回'CAFÉ'（带重音符号正常保留） - MySQL 依赖字符集，如果列是
utf8mb4_bin，UPPER()仍能正确处理 Unicode；但旧的latin1可能丢失 ß→SS 这类映射 - SQL Server 的
UPPER()受数据库排序规则（collation）影响，比如Latin1_General_CI_AS支持德语变音，而SQL_Latin1_General_CP1258_CI_AS可能不识别某些越南字符
性能和索引注意事项
在 WHERE 条件里用 UPPER(column) 会导致索引失效——因为数据库无法用原始索引直接匹配转换后的值。
例如：WHERE UPPER(email) = 'JOE@EXAMPLE.COM' 通常走全表扫描。
更高效的做法：
- 建函数索引（PostgreSQL/Oracle 支持）：
CREATE INDEX idx_email_upper ON users (UPPER(email)); - SQL Server 可用计算列 + 索引
- MySQL 8.0+ 支持函数索引，但需显式定义：
CREATE INDEX idx_upper_name ON users ((UPPER(name))); - 或者干脆存标准化值（如
email_upper字段），写入时就计算好
大小写转换看着简单，真正上线时最容易被忽略的是排序规则兼容性和函数索引的缺失。
