非主键字段JOIN索引大概率失效，因区分度低、隐式转换、函数包裹、多对多膨胀及统计不准；修复需同步解决数据质量、索引结构和查询写法三层问题。
JOIN非主键字段时索引大概率失效
非主键字段（比如 user_name、order_no）通常没有默认索引，即使手动加了单列索引，也常因区分度低（如大量重复值）或统计信息不准，被优化器主动弃用。执行 EXPLAIN 会看到 type: ALL 或 type: index，意味着全表扫描或全索引扫描。
- 主键天然唯一、非空、高区分度，优化器几乎总能选中对应索引，走
eq_ref或ref - 非主键字段若存在大量 NULL 或重复值（如
status只有 'pending'/'done' 两种），索引选择性（selectivity）低于 0.1 时，MySQL 常认为走索引比全表扫描更慢 - 复合索引中若非主键字段不在最左前缀位置（如建了
(created_at, user_id)，但 JOIN 条件只用user_id），也无法命中
非主键JOIN容易触发隐式转换和函数包裹
业务中非主键字段常含格式干扰：订单号带前缀（'ORD-12345'）、手机号存为字符串、时间字段用 VARCHAR 存 '20240101'。一旦 JOIN 条件出现类型不一致（如 orders.order_no = users.ref_id，一边是 VARCHAR 一边是 BIGINT），数据库必须做隐式转换——这直接让索引失效。
- MySQL 会把数字转成字符串去比对，无法使用
order_no上的索引 - 开发者为“兼容格式”加
CONVERT(order_no, SIGNED)或SUBSTR(order_no, 5)，函数操作同样导致索引不可用 - JSON 字段里抽出来的 ID（如
JSON_EXTRACT(log.meta, '$.user_id')）默认是 JSON 类型，与 INT JOIN 必然触发转换
非主键关联常伴随多对多风险，放大中间结果集
主键/外键关联天然是一对一或一对多；而非主键字段（如 user_name）天然可能重复，JOIN 会无意中产生笛卡尔积。哪怕只有 100 行匹配，若平均每个名字对应 50 个用户，中间结果就是 5000 行——后续再 JOIN 第三张表，数据量指数级膨胀。
- 优化器难以准确预估这种膨胀，可能错误选择驱动表，让大结果集去驱动另一张大表
-
GROUP BY或ORDER BY跟在后面时，临时表极易写满磁盘（Using temporary; Using filesort） - 即使加了
LIMIT，数据库也得先算出全部中间结果再截断，无法提前终止
修复不是“加个索引”就完事
真要拿非主键字段 JOIN，得同步解决数据质量、索引结构、查询写法三层问题，否则只是掩耳盗铃。
- 先确认该字段是否真的需要 JOIN：能否冗余到主表（如把
user_name冗余进订单表），用主键关联替代 - 若必须用，确保字段 NOT NULL + 唯一约束（或业务层保证），再建联合索引，把该字段放最左位，并覆盖常用查询字段（避免回表）
- JOIN 条件里绝不要出现函数、类型转换、
LIKE '%xxx'；过滤条件尽量下推到驱动表（如WHERE order_no LIKE 'ORD-%' AND created_at > '2024-01-01'） - 用
EXPLAIN FORMAT=JSON查看rows_examined_per_scan和used_columns，确认索引是否真实生效
最常被忽略的一点：非主键字段的业务含义可能随时间漂移（比如早期订单号规则变更），索引建得再准，数据语义乱了，JOIN 结果本身就不对——性能再快也是错的。
