UPPER()仅格式化查询结果且不修改原数据，WHERE中滥用会致全表扫描；应优先调整collation实现大小写不敏感匹配，必要时建函数索引或计算列索引。
直接用 UPPER() 就行，但得清楚它不改原数据、只影响当前查询结果，且在 WHERE 里滥用会拖慢查询。
SELECT 中用 UPPER() 格式化输出
这是最安全、最常见的用法：把字段值转成大写后展示，不影响存储或索引。
-
UPPER()只接受一个参数，比如UPPER(name)或UPPER('hello world') - 非字母字符（数字、中文、标点、空格）原样保留，
UPPER('café123!')→'CAFÉ123!' - 传入
NULL返回NULL，不是空字符串，注意后续逻辑是否容忍NULL - 想拼接后再转大写？可以嵌套，比如
UPPER(CONCAT(first_name, ' ', last_name))，但别多层套UPPER(UPPER(x))——纯属冗余
WHERE 中用 UPPER() 做大小写不敏感匹配
看着方便，实际是性能陷阱。数据库无法使用 email 字段上的普通索引去加速 UPPER(email) = 'ABC@EXAMPLE.COM' 这类条件，大概率触发全表扫描。
- 优先改字段的
COLLATION：比如 MySQL 设为utf8mb4_general_ci，SQL Server 设为SQL_Latin1_General_CP1_CI_AS，之后直接WHERE email = 'abc@example.com'就自动忽略大小写 - 实在要函数兜底，MySQL 8.0+ 可建函数索引：
CREATE INDEX idx_email_upper ON users (UPPER(email)); - SQL Server 可走计算列 + 索引：
ALTER TABLE users ADD email_upper AS UPPER(email); CREATE INDEX IX_users_email_upper ON users(email_upper); - SQLite 默认不区分大小写比较，但
UPPER('café')行为不稳定，别依赖
UPDATE 时用 UPPER() 批量转存大写
这会真正修改数据，动作不可逆，必须提前验证。
- 先加
WHERE条件过滤：比如UPDATE users SET name = UPPER(name) WHERE name != UPPER(name)，避免无意义更新和 binlog 冗余 - 检查字段长度：如果原是
VARCHAR(20)，而某些 Unicode 字符在 UPPER 后字节变长（虽 ASCII 字母不会），可能截断或报错 - 警惕唯一约束冲突：
UPPER('Abc')和UPPER('ABC')结果一样，若该字段有UNIQUE，UPDATE 可能失败 - 别在事务里盲目跑全表 UPDATE，尤其大表；建议分批，比如加
WHERE id BETWEEN 1000 AND 2000
跨数据库的 UPPER() 兼容性差异
语法一致不等于行为一致，线上环境务必实测。
- PostgreSQL 对非 ASCII 字符（如德语 ß、土耳其语 İ）支持较弱，
UPPER('straße')可能不转成'STRASSE'，得靠icu扩展 - SQL Server 的
Latin1_General_CI_AS能正确处理 ß → SS，但SQL_Latin1_General_CP1_CI_AS不行 - MySQL 的
UPPER()和UCASE()完全等价，选哪个纯看团队规范 - Oracle 和 SQLite 的
UPPER()对中文、日文无影响，只动 a–z，这点倒是一致
真正麻烦的从来不是怎么写 UPPER()，而是没想清楚：这个转换该在入库时做、查询时做，还是交给应用层做；以及，你用的 collation 是否已经悄悄帮你解决了问题。
