JOIN的ON子句中使用UPPER()、DATE()等函数会导致索引直接失效，因B+树索引存储原始值而非计算结果，EXPLAIN中表现为key为NULL、type为ALL；应避免函数调用，统一字段类型与字符集，必要时用生成列+索引或应用层归一化。
JOIN的ON子句里用UPPER()、DATE()这类函数，索引直接失效
MySQL优化器在评估JOIN条件时，只要看到索引列被任何函数包裹（比如 UPPER(a.name)、DATE(o.created_at)、CONCAT(b.prefix, b.id)），就无法利用该列上的索引——因为B+树索引存的是原始值，不是函数计算后的结果。
常见错误现象：EXPLAIN 中 type 为 ALL 或 index，key 为 NULL，Extra 出现 Using where; Using join buffer。
- 别在
ON里写ON UPPER(u.email) = UPPER(o.email)，哪怕两边都有email索引 - 日期范围 JOIN 也别写
ON DATE(o.order_time) = DATE(u.reg_time)，这等于放弃索引 - 如果业务真要忽略大小写比对，优先改字符集和
COLLATION（如设为utf8mb4_unicode_ci），而不是靠UPPER() - 时间字段 JOIN 应该用原生类型对齐：确保
o.order_time和u.reg_time都是DATETIME，然后直接ON o.order_time = u.reg_time
函数索引（Generated Column + Index）不是万能解药
MySQL 5.7+ 支持函数索引，即通过生成列（GENERATED COLUMN）加索引的方式绕过限制，但它只适用于你**能控制建表结构**且**函数逻辑固定**的场景。
典型误用：以为建了 ALTER TABLE users ADD email_upper VARCHAR(255) AS (UPPER(email)) STORED + INDEX idx_email_upper (email_upper)，就能在 ON UPPER(u.email) = o.email_upper 中生效——其实不行，因为 JOIN 条件仍含函数调用，优化器不识别这种“对称映射”。
- 真正有效的写法是：把关联逻辑搬到生成列一侧，例如
ON u.email_upper = o.email_upper，两边都用生成列 - 但注意：生成列本身有存储开销，且
STORED列会占用磁盘空间；VIRTUAL列虽不占空间，但 JOIN 时仍需实时计算，性能未必更好 - 若 JOIN 条件涉及多个不同函数变体（比如有时比前缀、有时比后缀），生成列方案会迅速失控，不如前置清洗或应用层归一化
为什么CAST()或CONVERT()在ON里也大概率让索引失效
显式类型转换看似可控，但在 JOIN 的 ON 子句中，它和隐式转换一样，会让优化器放弃索引——因为转换操作发生在每一行匹配时，无法利用索引的有序性做快速定位。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
比如 orders.user_id 是 VARCHAR，users.id 是 INT，写成 ON CAST(o.user_id AS SIGNED) = u.id，看起来“主动转换了”，但实际 o.user_id 上的索引还是不会被使用。
-
EXPLAIN里possible_keys可能显示有索引，但key仍是NULL - 真正起作用的是“哪边被转换”：如果驱动表字段被转换（如
CAST(u.id AS CHAR)），那驱动表索引失效；如果被驱动表字段被转换（如CAST(o.user_id AS SIGNED)），则被驱动表索引失效 - 唯一稳妥路径是统一字段类型：用
ALTER TABLE orders MODIFY user_id INT，而不是在 SQL 层补救
检查ON条件是否“干净”的实操步骤
别猜，直接看执行计划并反向验证字段使用方式。重点不是“有没有索引”，而是“索引列是否以原始形式出现在等值条件左侧/右侧”。
- 运行
EXPLAIN FORMAT=TRADITIONAL SELECT ... FROM t1 JOIN t2 ON ...，确认key列非NULL，且type至少是ref或更好 - 用
SHOW CREATE TABLE t1和SHOW CREATE TABLE t2对比两个 JOIN 字段的DATA_TYPE、COLLATION、NULL属性是否完全一致 - 把 ON 条件单独拎出来，在 WHERE 中模拟测试：比如
SELECT * FROM t1 WHERE t1.col = 'xxx'看是否走索引，再换成WHERE UPPER(t1.col) = 'XXX'对比 - 如果用了 ORM（如 Laravel Eloquent、MyBatis），检查生成的 SQL 是否悄悄加了函数——有些框架对字符串字段默认套
LOWER()或TRIM()
最常被忽略的一点：即使所有字段类型一致、没函数、也有索引，若统计信息过期（ANALYZE TABLE 没跑过），优化器也可能误判驱动表顺序，导致本该走索引的被驱动表退化为全表扫描。
