不同字符集表关联时inner-Join与left-Join的差异分析

1. 隐式转换与索引可用性差异 #

• LEFT JOIN场景：你的SQL里左表n_order是utf8mb4字符集，右表t_vehicle是utf8。由于LEFT JOIN必须保留左表所有符合WHERE条件的行，优化器只能以左表为驱动表。关联时MySQL会自动将右表的v.vehicle_license隐式转换为utf8mb4（utf8mb4是utf8的超集），这相当于在右表字段上执行了转换函数，直接导致t_vehicle的vehicle_license索引失效，只能走全表扫描，最终触发低效的Block Nested-Loop连接算法，性能暴跌。
• INNER JOIN场景：INNER JOIN是等价连接，优化器可以自由调整连接顺序。它会根据表的行数、索引情况选择最优驱动表，比如如果t_vehicle数据量更小，会优先扫描t_vehicle，并可能将左表的o.vehicle_license转换为utf8（仅保留两者兼容的字符，不影响匹配结果），此时t_vehicle的索引可以正常使用，匹配效率大幅提升。

2. 连接顺序的优化空间差异 #

• LEFT JOIN的结果集必须包含左表所有符合WHERE条件的行，优化器无法交换左右表的连接顺序，只能固定以左表为驱动表，即使右表的索引无法利用，也只能硬着头皮做全表匹配。
• INNER JOIN的结果仅保留两张表的匹配行，优化器可以灵活选择驱动表和连接方式，优先选择能利用索引、数据量更小的表作为驱动方，避免低效的全表扫描和连接算法。

3. 隐式转换的代价承担方不同 #

• LEFT JOIN中，隐式转换发生在被驱动表（右表）的字段上，索引失效后，每一行驱动表数据都要遍历大量被驱动表数据，代价极高。
• INNER JOIN中，优化器可以将转换转移到驱动表字段上，或者选择更优的转换方向，确保索引能被有效利用，匹配代价大幅降低。

快速解决方法 #

• 统一两张表的字符集为utf8mb4（推荐，支持所有Unicode字符，彻底避免隐式转换问题）。
• 若无法修改表字符集，可在关联条件中显式转换左表字段为utf8：CONVERT(o.vehicle_license USING utf8) = v.vehicle_license，但要注意左表字段若包含utf8不支持的字符会被截断，可能导致匹配错误。
• 给t_vehicle的vehicle_license创建utf8mb4字符集的索引：ALTER TABLE t_vehicle ADD INDEX idx_vehicle_license_utf8mb4 (vehicle_license) CHARACTER SET utf8mb4;，这样隐式转换后仍能匹配到索引。

内容的提问来源于stack exchange，提问作者bluelullaby