被驱动表连接字段必须有索引，否则JOIN必然退化为全表扫描；字段类型、字符集、排序规则不一致会导致隐式转换，使索引失效；FORCE INDEX对被驱动表无效，优化应聚焦于被驱动表索引建设与一致性校验。
关联字段没索引，JOIN 就大概率退化为全表扫描——不是“可能”，而是几乎必然。
被驱动表的连接字段必须有索引
MySQL 在执行 JOIN 时，会先选一个驱动表（通常是 FROM 后的第一个表），再对被驱动表（ON 右侧那个）按连接条件逐行查找匹配。如果被驱动表的连接字段没索引，就只能扫全表去比对。
- 典型错误写法：
SELECT * FROM orders o JOIN users u ON o.user_id = u.id，但users.id是主键却没建索引（比如误删、或建表时漏了PRIMARY KEY） - 复合条件更危险：
ON a.x = b.x AND a.y = b.y，结果只在b.x上建了单列索引，b.y完全没索引 →b表仍全扫 - 验证方法：用
SHOW CREATE TABLE users确认id列是否真有PRIMARY KEY或KEY；别只看字段名像主键就默认它有效
字段类型不一致导致隐式转换，索引形同虚设
哪怕两边都建了索引，只要类型不一致（比如 orders.user_id 是 VARCHAR，users.id 是 INT），MySQL 就会在某一边加 CAST()，让索引列实际参与了函数运算，优化器直接弃用。
- 常见现象：
EXPLAIN中type显示ALL，key为NULL，Extra出现Using where; Using join buffer (Block Nested Loop) - 不止是数值/字符串问题：两边都是
VARCHAR，但COLLATE不同（如utf8mb4_0900_ai_civsutf8mb4_unicode_ci）也会失效 - 检查命令：
DESCRIBE orders和DESCRIBE users对比字段类型、长度、Collation；连接层也要确认：SHOW VARIABLES LIKE 'character_set%'
FORCE INDEX 对被驱动表完全无效
FORCE INDEX 只能指定驱动表用哪个索引，对被驱动表的索引选择毫无影响。强行加它，反而可能掩盖真正的问题。
- 误用示例：
SELECT * FROM orders FORCE INDEX(idx_user_id) JOIN users ON orders.user_id = users.id—— 若users.id没索引，这个FORCE一点作用没有 - 数据倾斜时更危险：比如 90% 的订单指向同一个
user_id，强制走idx_user_id会导致大量回表，性能比全表扫描还差 - 正确做法：先跑
EXPLAIN FORMAT=TRADITIONAL，明确哪张是驱动表、哪张是被驱动表；只在被驱动表补索引，而不是在驱动表上硬拗
最容易被忽略的是：字符集和排序规则（COLLATION）不一致，不会报错，也不提示警告，但会让索引彻底失效——连 EXPLAIN 都看不出明显异常，只能靠对比 SHOW CREATE TABLE 和连接变量一点点抠。
