结论：JOIN条件中对关联字段使用UPPER()、DATE()等函数会导致索引彻底失效，因优化器无法将函数结果映射到B+树索引，被迫全表扫描；修复须前置标准化（如生成列+索引）或统一字段类型与字符集，而非依赖函数索引或强制提示。
JOIN条件里用UPPER()、DATE()这类函数，索引直接失效
只要在ON子句中对任意一侧的关联字段调用函数，该字段的索引就彻底作废。不是“可能不用”，而是优化器根本无法将函数结果映射到B+树索引结构上——它得先算出每行的函数值，再逐个比对，等于主动放弃索引。
常见错误写法：
-
ON u.email = UPPER(o.email)（o.email索引失效） -
ON a.order_date = DATE(b.ship_time)（b.ship_time索引失效） -
ON t1.code = CONCAT('ORD-', t2.id)（t2.id索引失效）
这类写法在小表上可能不明显，但一旦数据量过10万，EXPLAIN里type会变成ALL，rows接近表总行数，Extra出现Using join buffer (Block Nested Loop)——这就是全表扫描的铁证。
为什么不能靠“加索引”来补救函数表达式
你没法给UPPER(email)建函数索引（MySQL 5.7不支持，8.0+虽支持但仅限于确定性函数且有严格限制），更关键的是：即使你建了INDEX idx_upper_email (UPPER(email))，JOIN时写成ON UPPER(u.email) = UPPER(o.email)，也只有一侧能用上——另一侧仍要计算，优化器大概率弃用整个路径。
真正可行的思路是把函数逻辑前置：
- 业务层统一存储规范值（比如邮箱全小写存入，查询时也不用
UPPER） - 用生成列（generated column）+索引替代：如
ALTER TABLE users ADD email_lower VARCHAR(255) AS (LOWER(email)) STORED，再对email_lower建索引 - 如果必须兼容大小写混合输入，改用
CASE或应用层标准化，而非在SQL里现场转换
LEFT JOIN右表字段用函数，问题更隐蔽
很多人只盯着左表（驱动表）有没有索引，却忽略LEFT JOIN的右表字段一旦被函数包裹，不仅自身索引失效，还会导致优化器放弃哈希连接（Hash Join），强行退化为嵌套循环（Nested Loop），性能断崖下跌。
典型陷阱：
-
LEFT JOIN orders o ON o.user_id = u.id AND YEAR(o.create_time) = 2023→o.create_time索引失效，且o表失去高效过滤能力 -
LEFT JOIN logs l ON l.trace_id = SUBSTR(u.token, 1, 16)→l.trace_id索引完全没机会用
这时EXPLAIN常显示右表type=ALL，而rows暴增——不是数据多，是优化器找不到索引入口。
隐式转换和函数失效，其实是一回事
你以为只是“类型不一致”？其实MySQL在做隐式转换时，本质就是在关联字段上偷偷加了一个隐式函数调用。比如user_id INT vs order.user_id VARCHAR，写ON u.id = o.user_id，MySQL实际执行的是ON u.id = CAST(o.user_id AS SIGNED)——这跟明写CAST没区别，索引照样失效。
验证方法很简单：SHOW CREATE TABLE比对两边字段的DATA_TYPE、COLLATION_NAME、是否NOT NULL；修复优先级是：统一类型 > 统一字符集 > 避免NULL干扰 > 最后才考虑STRAIGHT_JOIN硬指定驱动表。
最易被忽略的一点：哪怕你把所有字段类型、字符集、NULL约束都对齐了，只要JOIN条件里出现任何函数、运算、或隐式转换，复合索引的最左前缀规则就自动失效——索引不是摆设，是精密匹配的契约。
