正确写法是where upper(name) = upper('john')，必须两端同步转换才能实现大小写不敏感精确匹配；只转一边会导致漏匹配或索引失效，而collate方案跨库兼容性差、行为不一致。
UPPER函数在WHERE子句中做大小写无关匹配的正确写法
直接对字段和参数都用UPPER()包裹是最稳妥的方式。数据库不会自动把索引字段转成大写去匹配，所以只转一边会导致索引失效或漏匹配。
常见错误是只写WHERE UPPER(name) = 'JOHN'却忘了把右边也转——其实右边字符串字面量本身是确定的，不转也能比，但一旦右边是变量或来自另一张表，大小写不一致就查不到。
- 正确：
WHERE UPPER(name) = UPPER('john') - 错误：
WHERE UPPER(name) = 'john'（右边小写，左边大写，永远不等） - 更错：
WHERE name = UPPER('john')（左边原值，右边大写，除非name本来就是全大写）
为什么不能只靠数据库COLLATION解决
有些同学会想：我设了utf8mb4_0900_as_cs或utf8mb4_unicode_ci不就完事了？确实，某些COLLATION支持大小写不敏感比较，比如_ci结尾的，但问题在于：
- 不是所有字段都建在
_ci排序规则下，尤其老库或迁移来的表可能用_cs（区分大小写） -
LIKE和=行为可能不一致，比如WHERE name LIKE 'john%'在_ci下能命中JohnDoe，但显式用UPPER更可控 - 跨库/跨版本时COLLATION行为可能有差异，
UPPER()语义稳定
性能影响与索引注意事项
UPPER(column)会让数据库无法使用column上的普通B-tree索引——因为索引存的是原始值，不是大写结果。
如果查询频繁且数据量大，得考虑函数索引（MySQL 8.0.13+、PostgreSQL、Oracle都支持）：
CREATE INDEX idx_name_upper ON users (UPPER(name));
否则只能接受全表扫描，或者改用COLLATE utf8mb4_0900_as_cs临时转换（MySQL）：
-
WHERE name COLLATE utf8mb4_0900_as_cs = 'john'（注意：这是大小写敏感对比） -
WHERE name COLLATE utf8mb4_0900_as_cs = 'JOHN'（同上，仍敏感） - 真正要大小写不敏感，得用
utf8mb4_0900_as_cs不行，得用utf8mb4_0900_as_ci——但前提是字段本身定义支持
不同数据库里UPPER的行为差异
UPPER()看着简单，但细节常踩坑：
- MySQL：支持中文、emoji，
UPPER('你好')不变，安全 - PostgreSQL：默认C locale下
UPPER('café')→'CAFÉ'，但某些locale可能不转重音符；建议搭配COLLATE "en_US.utf8"用 - SQL Server：
UPPER(N'café')正常，但若列是varchar非nvarchar，可能丢字符 - SQLite：不区分大小写比较默认就生效（
LIKE和=都如此），UPPER()反而多余，除非你刻意要标准化输出
多语言环境别假设UPPER()一定“安全”，尤其涉及德语ß、土耳其语i/I映射时，数据库底层ICU版本会影响结果。
