JOIN时大小写不一致会导致关联错误而非脏数据入库；若两边collation不一致（如_ci与_cs混用），会漏匹配或误关联，造成聚合统计严重偏差；ALTER改collation风险高且破坏现有查询；安全做法是在ON中用UPPER()双侧归一化，并配合MySQL 8.0+函数索引优化性能。
直接用大小写不一致的字符串字段做 JOIN，不会导致“脏数据入库”，但会引发严重的关联错误——本该合并的记录被漏掉，本该隔离的记录被错误关联，最终产出逻辑错误的结果集。这不是入库问题，而是查询层的数据语义崩塌。
JOIN时大小写不敏感让‘Alice’和‘alice’变成两个不同用户
当 user.name 存的是 'Alice'，而 order.customer_name 存的是 'alice'，在默认 utf8mb4_0900_as_cs（区分大小写）或 utf8mb4_unicode_ci（不区分）下行为完全不同：
- 若两边 collation 都是
_ci（如utf8mb4_unicode_ci），ON t1.name = t2.customer_name会匹配成功——但这是靠规则“模糊”出来的，不是业务本意； - 若一边是
_cs或_bin，另一边是_ci，则可能一半匹配一半丢，结果不可控； - 最危险的是：开发以为“已关联上”，实际只连上了大写开头的那部分，小写记录全进
NULL，聚合统计少算 30%–50%，且毫无报错提示。
为什么不能靠 ALTER TABLE 改 collation 一劳永逸
改列的 COLLATE 看似彻底，但实际踩坑密集：
-
ALTER TABLE users MODIFY name VARCHAR(50) COLLATE utf8mb4_bin会锁表，线上库执行风险高； - 改完后，所有已有
WHERE name = 'alice'查询突然失效（原来能查到，现在查不到），应用层集体报错； - 如果该字段还被用于全文索引、JSON 函数或分区键，
_bin可能直接报错不兼容； - 跨库同步时，目标库 collation 不同（比如从 MySQL 同步到 PostgreSQL），改源端 collation 对下游无效。
UPPER() 在 JOIN 条件里用对了才安全
真正可控的做法，是在 ON 子句中显式归一化，而不是依赖底层配置：
- ✅ 正确：
ON UPPER(t1.name) = UPPER(t2.customer_name)—— 两边都转，NULL 安全，语义确定； - ❌ 错误：
WHERE UPPER(t1.name) = 'ALICE'——t1.name上的索引完全失效，全表扫描； - ⚠️ 注意：
UPPER()对中文、emoji、全角字符无副作用，但对含不可见字符（如\u200b零宽空格）的字段，必须先TRIM()再UPPER()； - 性能补救：MySQL 8.0+ 可建函数索引
CREATE INDEX idx_upper_name ON users ((UPPER(name)))，括号不能省。
真正麻烦的从来不是单个字段大小写，而是多个来源系统各自按自己规则存名——有的导出带空格，有的 API 自动转小写，有的前端提交首字母大写。这时候，靠数据库配置兜底根本不可靠，只有在 JOIN 当前上下文里做标准化，才能保证每次结果可重现。
