JOIN ON中使用UPPER()、DATE()等函数会导致索引失效，因优化器无法对齐函数输出与B+树有序结构；正确做法是建函数索引或提前标准化存储。
JOIN ON里用UPPER()、DATE()这类函数直接让索引失效
只要ON子句里对任意字段套了函数，比如UPPER(a.name) = UPPER(b.name)或DATE(a.created_at) = DATE(b.date)，数据库就大概率放弃走索引。优化器没法把函数输出值和B+树索引的有序结构对齐——它不知道UPPER()之后的值是否还保持单调性，也不敢下推过滤条件。
常见错误现象：
- 执行计划中被驱动表的
type变成ALL，key为空 - 哪怕两边字段类型、字符集、索引都一模一样，照样全表扫描
- PostgreSQL 还可能因隐式转换把整张大表 cast 成
text再比对，500 万行订单表耗时从 80ms 涨到 6.2s
字符集或COLLATION不一致时硬加COLLATE更慢
有人发现 JOIN 慢，就想着在 ON 里补 COLLATE 强制统一，比如t1.name COLLATE utf8mb4_0900_as_cs = t2.name COLLATE utf8mb4_0900_as_cs。这看似绕过了报错，但实际几乎不解决问题。
原因很实在：
- MySQL 优化器会在生成执行计划前做语义推导，只要字段原始
COLLATION不同，就大概率拒绝走索引 - 这种写法无法命中已有索引，等效于在每行上实时计算 collation 转换，CPU 开销翻倍
- 正确做法是用
ALTER TABLE MODIFY统一字段定义，且必须同时指定CHARACTER SET和COLLATE
想用函数又想快？只有两种靠谱路径
真有业务必须做大小写不敏感或日期截断匹配，不能靠 ON 里硬套函数临时应付。
可选方案：
- 建函数索引（MySQL 8.0+/PostgreSQL）：
CREATE INDEX idx_users_name_lower ON users ((LOWER(name)))，然后ON里写LOWER(a.name) = LOWER(b.name) - 提前标准化存储：用户注册时就把
name存为小写，JOIN直接用原始字段比对，零运行时开销 - 避免在 JOIN 中处理时间精度：不要用
DATE(order_time) = '2026-07-20'，改用order_time >= '2026-07-20' AND order_time ，才能走 <code>order_time上的索引
真正卡住性能的，往往不是函数本身多慢
而是它让数据库彻底放弃索引路径，退化成暴力匹配。检查 EXPLAIN 里被驱动表的 type 和 key，比看 SQL 写得“多优雅”管用得多。
最容易被忽略的一点：即使你给字段建了索引，只要 ON 里一裹函数，那索引就形同虚设——它不会报错，也不会警告，只是默默变慢。
