幻读是事务中两次相同范围查询返回行数不同的现象，由其他事务插入符合查询条件的新行导致；而非唯一索引列用于JOIN引发的是结果集膨胀或语义错误，并非真正幻读。
关联非唯一索引列本身不会直接导致“幻读”——幻读（Phantom Read）是事务隔离级别定义的特定现象，指同一事务中两次 SELECT 返回行数不同，因其他事务插入了符合查询条件的新行。而 JOIN 中用非唯一列（如 user_id）关联，真正引发的是**结果集重复、膨胀或语义错误**，不是标准意义上的幻读。混淆常源于对现象的误命名：你看到“多出几倍数据”，以为是幻读，其实是笛卡尔积失控或逻辑歧义。
为什么非唯一索引列会让JOIN结果“看起来像幻读”
因为非唯一列无法保证一对一匹配，JOIN 时会自然产生一对多或多对多组合。数据库按 ON 条件做配对，不校验唯一性；只要值相等就拼接。例如：
-
orders表有 3 条user_id = 100的订单 -
user_profiles表有 2 条user_id = 100的记录（比如历史快照、多语言配置） -
SELECT * FROM orders o JOIN user_profiles p ON o.user_id = p.user_id会返回 3 × 2 = 6 行，而非直觉中的“每个订单配一个 profile”
这种数量突变，在业务层表现为“数据凭空多出来”，尤其当上层代码没做去重或聚合时，容易被当成幻读。但本质是逻辑设计缺陷，不是隔离级别问题。
ON 条件用非唯一列时，LEFT JOIN 和 INNER JOIN 行为差异极大
非唯一列放大了 ON 与 WHERE 的执行阶段差异，尤其在 LEFT JOIN 中：
- 写法一（过滤放在
ON）：LEFT JOIN user_profiles p ON o.user_id = p.user_id AND p.lang = 'zh'→ 只对匹配lang = 'zh'的 profile 做关联，没匹配上的订单仍保留，p.*为 NULL - 写法二（过滤放在
WHERE）：LEFT JOIN user_profiles p ON o.user_id = p.user_id WHERE p.lang = 'zh'→ 先全量关联（可能产生多对多），再整体过滤，结果中所有p.lang != 'zh'的行（包括 NULL）都被剔除，LEFT JOIN退化为INNER JOIN
这个区别在非唯一列上尤为致命：一旦 profile 表里一个 user_id 对应多个 lang，写法二会直接丢掉该用户的全部订单记录。
如何避免非唯一列 JOIN 引发的结果错乱
核心是让关联具备确定性，而不是依赖索引是否唯一：
- 优先使用主键或带业务唯一约束的列做关联（如
users.id、orders.order_no），而非泛化的外键字段（如user_id） - 若必须用非唯一列，加额外限定条件收窄匹配范围，例如：
ON o.user_id = p.user_id AND p.is_active = 1 AND p.updated_at = (SELECT MAX(updated_at) FROM user_profiles p2 WHERE p2.user_id = p.user_id) - 用子查询或窗口函数预聚合被驱动表，确保每条左表记录最多匹配一条右表记录，例如：
(SELECT * FROM user_profiles p2 WHERE p2.user_id = o.user_id ORDER BY p2.updated_at DESC LIMIT 1) - 检查执行计划：
EXPLAIN中若type是ALL或index，说明没走索引，非唯一列又无有效过滤，性能和结果都不可控
真正危险的不是“非唯一索引”，而是把非唯一列当成了隐含的“一对一契约”。数据库从不替你保证这点，它只忠实地执行配对逻辑。你看到的每一行重复，都是你写的 ON 条件放过的组合。
