直接JOIN会漏掉本该匹配的记录，因为数据库默认区分大小写导致‘Alice’与‘alice’无法关联，需用UPPER()函数在JOIN条件中两边统一转大写，兼顾兼容性与NULL安全。

为什么直接JOIN会漏掉本该匹配的记录

当两个表用字符串字段做JOIN，比如 user.name 和 order.customer_name，但一方存的是 'Alice'，另一方是 'alice' 或 'ALICE'，数据库默认按字节比较（尤其 PostgreSQL、SQL Server 默认区分大小写），结果就是这些逻辑上相同的记录无法关联上。

这不是数据“脏”，而是比较规则和业务语义不一致。盲目改数据库排序规则（collation）影响面太大，临时方案首选字段级标准化。

UPPER() 是最稳妥的大小写归一化手段

UPPER() 函数把字符串全转成大写，兼容性极好：MySQL、PostgreSQL、SQL Server、Oracle、SQLite 全支持，且对 NULL 安全（返回 NULL，不会报错）。

关键不是“用不用函数”，而是**两边都用、且只在 JOIN 条件里用**——避免在 WHERE 或 SELECT 中滥用导致索引失效。

• ✅ 正确： ON UPPER(t1.name) = UPPER(t2.customer_name)
• ❌ 危险： WHERE UPPER(t1.name) = 'ALICE'（t1.name 上的索引基本失效）
• ⚠️ 注意：如果字段可能含空格或不可见字符，先 TRIM() 再 UPPER()

性能隐患：UPPER() 会让索引失效，怎么缓解

直接在 JOIN 字段上套 UPPER()，数据库无法使用原始列上的 B-Tree 索引，全表扫描风险高。有三类应对方式：

• 建函数索引（PostgreSQL/Oracle）：CREATE INDEX idx_upper_name ON users (UPPER(name));
• 加计算列+索引（SQL Server）：ALTER TABLE users ADD name_upper AS UPPER(name); CREATE INDEX IX_name_upper ON users(name_upper);
• 业务层预处理：导数或同步时就存一份 name_upper 字段，JOIN 直接用它（最可控）

MySQL 8.0+ 支持函数索引，但语法是 CREATE INDEX idx ON t ((UPPER(col)))，括号不能少，漏了就建失败。

别忽略 COLLATE 的隐式行为

有些场景看似没用函数也“能连上”，比如 MySQL 默认 utf8mb4_0900_as_cs 是区分大小写的，但如果你的列定义带了 COLLATE utf8mb4_unicode_ci（_ci 表示 case-insensitive），那 JOIN 本身就忽略大小写——这时硬加 UPPER() 反而多此一举，还拖慢速度。

查清楚实际 collation 才决定要不要函数干预：SHOW FULL COLUMNS FROM table_name LIKE 'col_name'; 看 Collation 列值。

真正麻烦的是混合环境：一个库用 _ci，另一个用 _cs，或者跨数据库同步——这种时候，UPPER() 是唯一不依赖底层配置的确定性方案。