UPPER函数用于将字符串中小写字母转为大写，不改变数字、符号、中文等非字母字符；适用于大小写无关匹配、数据标准化和报表输出，但WHERE中使用可能影响索引性能。
UPPER函数的基本用法和适用场景
SQL里把小写字母转成大写，最直接可靠的方式就是用UPPER()函数。它在主流数据库（MySQL、PostgreSQL、SQL Server、Oracle、SQLite）中都支持，行为一致：只对ASCII字母和部分Unicode大写映射字符生效，数字、符号、空格、中文等原样返回。
常见使用场景包括：统一用户名/邮箱比对、生成规范报表字段、清洗导入数据时的大小写不一致问题。
-
UPPER('hello world')→'HELLO WORLD' -
UPPER('User123!@#')→'USER123!@#'（数字和符号不变） -
UPPER('你好abc')→'你好ABC'（中文不受影响）
WHERE条件中用UPPER做大小写无关匹配
很多开发者想“忽略大小写查用户”，却直接写WHERE name = 'admin'——这在区分大小写的排序规则（如MySQL的utf8mb4_bin）下会漏掉'Admin'或'ADMIN'。正确做法是两边都转大写再比：
SELECT * FROM users WHERE UPPER(name) = UPPER('admin');注意两点：
- 如果
name字段没建函数索引，这个查询无法走普通B-tree索引，可能全表扫描——大数据量时性能明显下降 - PostgreSQL需额外创建表达式索引：
CREATE INDEX idx_users_name_upper ON users (UPPER(name)); - SQL Server和Oracle能隐式利用函数索引（若已建），但MySQL 5.7及以前不支持函数索引，8.0+才支持
UPPER(name)索引
UPPER和COLLATE混用时的冲突风险
在MySQL或SQL Server中，如果字段本身用了大小写敏感的校对规则（如utf8mb4_0900_as_cs或SQL_Latin1_General_CP1_CS_AS），再套UPPER()通常没问题；但若同时显式指定COLLATE，可能触发隐式转换警告甚至报错。
例如这条语句在MySQL中会报错：
SELECT UPPER('abc' COLLATE utf8mb4_0900_as_cs);因为COLLATE绑定的是字符串字面量，而UPPER()期望接收一个可转换的字符值。稳妥写法是先保证输入无显式COLLATE，或用CONVERT() / CAST()预处理：
- ✅ 安全写法：
UPPER(CAST('abc' AS CHAR)) - ✅ 或：
UPPER(CONVERT('abc', CHAR)) - ❌ 避免：
UPPER('abc' COLLATE ...)（多数引擎不接受）
不同数据库对非ASCII字符的支持差异
UPPER()对带重音符号的拉丁字母（如é→É）、德语ß、土耳其语i/I映射等，各数据库实现不一。PostgreSQL默认依赖系统locale，MySQL依赖字段校对规则，SQL Server则严格按Windows locale。
典型差异：
- MySQL +
utf8mb4_unicode_ci：能正确处理café→CAFÉ - PostgreSQL（C locale）：
UPPER('café')可能返回'CAFÉ'或'CAFÉ'（取决于lc_ctype设置） - SQL Server：
UPPER(N'İstanbul')（带点大写I）在Turkish排序规则下结果不同于Latin1
生产环境涉及多语言时，别只靠UPPER()做业务逻辑判断——优先用标准化的Unicode大小写折叠（如Python的str.casefold()），SQL层仅作展示层转换。
