join on中使用upper()、date()等函数会导致索引彻底失效，因优化器无法将函数结果映射到b+树索引，被迫全表扫描；应改用生成列+索引（两边均引用生成列）、统一字段类型或范围查询替代。
JOIN ON里调用UPPER()、DATE()这类函数，索引直接作废
MySQL（以及PostgreSQL、Oracle等主流数据库）在执行JOIN时，只要ON子句中对索引字段施加了任何函数调用——比如UPPER(email)、DATE(created_at)、CONCAT('ORD-', id)——该字段的索引就完全无法被使用。这不是“可能不走”，而是优化器根本没法把函数结果映射到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索引失效
验证方式很简单：跑EXPLAIN，看到对应表的type是ALL、key为NULL、Extra里出现Using join buffer (Block Nested Loop)，就是铁证。
为什么不能靠函数索引或CAST()补救？
MySQL 8.0+虽支持生成列+索引（如email_lower VARCHAR(255) AS (LOWER(email)) STORED），但它只在你**把函数逻辑完全前置并固定在字段定义里**时才有效。一旦JOIN条件中仍含函数调用，比如ON UPPER(u.email) = o.email_lower，优化器依然识别不了这种“不对称映射”，索引还是用不上。
CAST()或CONVERT()在ON里也同理：它们本质是运行时转换，破坏了索引的有序性，优化器无法利用B+树做快速定位。哪怕类型看起来一致，只要出现显式转换，索引大概率失效。
更隐蔽的是LEFT JOIN场景：右表字段被函数包裹，不仅自身索引失效，还会迫使优化器放弃哈希连接，退化为嵌套循环，性能断崖下跌。
真正有效的替代方案只有三个方向
核心思路是把“运行时计算”变成“存储时归一化”或“查询时对齐”：
- 业务层统一规范输入：邮箱存小写、时间字段用原生
DATETIME类型、ID字段类型严格匹配（别用VARCHAR存数字） - 建生成列+索引，且JOIN时两边都用生成列：
ON u.email_lower = o.email_lower，而不是一边函数一边字段 - 范围类条件改写为闭区间：把
ON DATE(o.order_time) = '2024-01-01'换成ON o.order_time >= '2024-01-01' AND o.order_time
字符集/COLLATE不一致也会触发隐式转换，导致同样后果。用SHOW FULL COLUMNS FROM table_name检查Collation列，比单纯看字段类型更关键。
最容易被忽略的细节：驱动表和被驱动表都要查
很多人只盯着左表（FROM后第一个表）有没有索引，却忘了被驱动表（ON右侧表）的连接字段同样需要索引。比如SELECT * FROM orders o JOIN users u ON o.user_id = u.id，如果orders.user_id有索引但users.id没有（或者不是主键），照样全表扫描。
复合条件如ON a.x = b.x AND a.y = b.y，不能只给a.x建单列索引；优先建INDEX (x, y)这样的复合索引，并确保顺序匹配查询模式。另外，应用传参类型必须严格对齐：数值不用引号，字符串必加引号——WHERE user_id = '123'（user_id是INT）这种写法，MySQL会隐式转成字符串比对，索引照样失效。
