join条件中使用函数会导致索引失效，因为优化器无法在函数结果上直接使用索引，常退化为全表扫描；常见陷阱包括upper()、date()、隐式类型转换等；可通过生成列、函数索引或预处理绕过。
JOIN 条件里用了函数，为什么执行计划直接崩了
因为数据库无法在函数结果上直接使用索引。比如 ON UPPER(a.name) = b.name 或 ON DATE(a.create_time) = b.date，优化器看到的是“对列做运算后再比对”，它既不能复用 a.name 上的索引，也无法预估函数输出的分布，最终大概率放弃走索引，退化为全表扫描或嵌套循环逐行计算。
哪些函数写法会悄悄让索引失效
常见陷阱包括：
-
UPPER()、LOWER()、TRIM()等字符串函数作用于 JOIN 字段 -
DATE()、YEAR()、HOUR()等时间截断函数 - 隐式类型转换，如
ON a.user_id = b.user_code（a 是INT，b 是VARCHAR） - 表达式参与比较，如
ON a.id + 1 = b.parent_id
这些写法会让 key 列在 EXPLAIN 中显示为 NULL，type 变成 ALL 或 index，rows 暴涨——这是最直观的信号。
不改业务逻辑，怎么绕过函数导致的性能问题
核心思路是把函数从 JOIN 条件里“摘出来”，移到数据准备阶段：
- 对右表字段预先计算并建索引：比如要按
UPPER(name)关联，就在b表加个生成列name_upper VARCHAR(64) STORED AS (UPPER(name))，再给它建索引 - 左表也做同样处理，确保两边都是裸字段等值匹配
- 用视图或 CTE 预处理：先
SELECT id, UPPER(name) AS name_key FROM a，再和b.name_key关联 - MySQL 8.0+ 可用函数索引：
CREATE INDEX idx_b_name_upper ON b ((UPPER(name)))（注意括号写法）
为什么有些函数看似简单却更伤性能
像 COALESCE(a.field, 'N/A') 或 CASE WHEN 这类逻辑判断函数，在 JOIN 条件中不仅失效索引，还会干扰优化器对行数的估算。它可能误判关联后膨胀倍数，进而拒绝下推过滤、禁用哈希连接，甚至选错驱动表顺序。这类问题在 EXPLAIN FORMAT=TREE 里常表现为 “not using join buffer” 或 “using temporary”。
真正难处理的不是函数本身，而是它把“可索引的等值匹配”变成了“每行都要现场计算+比对”的 CPU 密集型操作——尤其当被驱动表有百万行时，开销是数量级的。
