UPPER和LOWER在WHERE中必须两端同步转换才能实现大小写无关精确匹配；只转一边会漏匹配或索引失效，推荐统一用LOWER并建函数索引，或优先使用ILIKE（PostgreSQL）、COLLATE（SQL Server）等原生方案。
UPPER 和 LOWER 函数在 WHERE 子句中必须成对使用
直接写 WHERE name = 'John' 是大小写敏感的，不同数据库行为不一致（比如 MySQL 默认不敏感，PostgreSQL 默认敏感）。要确保跨库一致且显式忽略大小写，必须对**两边都做统一转换**。只转字段不转字面量，或只转字面量不转字段，都会漏匹配。
正确写法是：WHERE UPPER(name) = UPPER('john') 或 WHERE LOWER(name) = LOWER('JOHN')。两者等价，选哪个取决于团队习惯，但别混用。
- 如果
name字段有索引，UPPER(name)会跳过索引（除非你建了函数索引） - MySQL 8.0+ 支持函数索引：
CREATE INDEX idx_name_upper ON users (UPPER(name)); - PostgreSQL 可用
CREATE INDEX idx_name_lower ON users (LOWER(name)); - SQLite 不支持函数索引，这种写法必然全表扫描
避免在 JOIN 条件里滥用 UPPER/LOWER
JOIN 时用 ON UPPER(a.name) = UPPER(b.name) 看似稳妥，但性能代价极大——尤其当两张表都无函数索引时，数据库无法有效利用任何现有索引，可能触发嵌套循环全量比对。
更优解是提前标准化数据：
- 在写入时就存
LOWER(name)到一个新列（如name_lower），并给它加索引 - JOIN 改为
ON a.name_lower = b.name_lower，走索引快得多 - 或者用带 collation 的列（如 MySQL 的
utf8mb4_0900_as_cs是区分大小写，utf8mb4_0900_ai_ci是不区分），让比较本身不依赖函数
注意 COLLATION 对 UPPER/LOWER 的隐性影响
某些字符在不同排序规则下，UPPER() 行为不同。比如土耳其语的 i → İ（带点大写 I），不是 I；德语的 ß 在部分 collation 下转 SS，而非 ß。如果你的业务涉及多语言用户，别只测英文样本。
验证方式很简单：
- MySQL：
SELECT UPPER('i') COLLATE utf8mb4_turkish_ci; - PostgreSQL：
SELECT UPPER('i' COLLATE "tr-TR-x-icu"); - 结果不等于
'I'就说明 collation 干预了函数行为
生产环境建议统一用 utf8mb4_0900_as_cs（MySQL）或 en_US.utf8（PostgreSQL）这类通用 collation，再配合 UPPER/LOWER，行为更可预期。
替代方案：用 ILIKE（PostgreSQL）或 COLLATE（SQL Server）更简洁
不是所有场景都非用 UPPER 不可。PostgreSQL 有原生不区分大小写的操作符 ILIKE：WHERE name ILIKE 'john'，语义清晰且优化器能更好规划执行计划。
SQL Server 可用 COLLATE 指定临时排序规则：WHERE name COLLATE SQL_Latin1_General_CP1_CI_AS = 'john'（CI 表示 case-insensitive）。
-
ILIKE不能用于 JOIN 条件的索引优化，但它比UPPER更易读 -
COLLATE在 SQL Server 中可作用于表达式，也支持函数索引 - MySQL 没有
ILIKE，但 8.0+ 支持COLLATE utf8mb4_0900_ai_ci，效果类似
真正容易被忽略的是：函数转换和 collation 方案在执行计划里表现完全不同，同一个查询在不同数据库上可能从毫秒变秒级——别只看语法对不对，一定看 EXPLAIN 输出的实际访问路径。
