核心问题是中间表缺失索引、复合索引顺序错误或JOIN字段类型不一致；必须显式为外键建单列或复合索引，按JOIN字段在左、WHERE等值条件在右的顺序排列，并确保两端字段类型、字符集完全一致。
多对多关联查得慢，核心问题往往出在中间表没索引、索引建错顺序，或JOIN时字段类型不一致——不是SQL写法本身有多复杂，而是数据库根本没法用索引快速定位。
中间表必须单独建索引，外键约束不等于索引
MySQL不会因为加了外键约束就自动创建索引。哪怕你执行过 ALTER TABLE order_product ADD CONSTRAINT fk_order_id FOREIGN KEY (order_id) REFERENCES orders(id)，order_id 和 product_id 字段依然可能没索引。
- 必须显式为两个外键字段分别建索引：
CREATE INDEX idx_order_id ON order_product(order_id)、CREATE INDEX idx_product_id ON order_product(product_id) - 如果查询常带条件（比如“查某订单下所有已发货商品”），优先建复合索引而非单列索引：
CREATE INDEX idx_order_status ON order_product(order_id, status) - 别在中间表上只建一个
(order_id, product_id)就完事——若查询是按product_id反查订单，这个索引完全无效，得补(product_id, order_id)
复合索引顺序决定JOIN能否走索引
中间表的复合索引不是随便排的。ON a.id = b.order_id AND b.status = 'shipped' 这种写法，只有索引 (order_id, status) 能生效；换成 (status, order_id)，order_id 就无法用于等值查找，JOIN退化为全表扫描。
- 原则：把 JOIN 字段放最左，WHERE 条件字段紧随其后（尤其是等值条件）
- 例如查“用户收藏的高评分商品”，语句含
JOIN favorites f ON u.id = f.user_id且WHERE f.score >= 4.5，索引应为(user_id, score)，不是(score, user_id) - 如果还要按时间排序，
ctime放最后：(user_id, score, ctime)——但注意，一旦出现范围条件（如>=），其后的字段就无法用于索引查找了
JOIN字段类型不一致会让索引彻底失效
中间表和主表字段类型稍有出入，比如 orders.id 是 BIGINT，而 order_product.order_id 是 INT，MySQL 在 JOIN 时会隐式转换，导致两边索引都用不上。
- 用
SHOW CREATE TABLE对比两端字段定义，确保类型、符号性（SIGNED/UNSIGNED）、长度（如VARCHAR(32)vsVARCHAR(64)）完全一致 - 字符串字段注意字符集和排序规则：
utf8mb4_general_ci和utf8mb4_unicode_ci不兼容，也会让索引失效 - 检查
EXPLAIN输出：如果type是ALL或index，且key列为空，大概率是类型或隐式转换问题
为什么EXPLAIN里key有值，但rows还是很大？
EXPLAIN 显示用了索引，不代表真高效。关键看 rows 和 Extra 字段：
-
rows值接近表总行数？说明索引没过滤掉多少数据，可能是字段选择性太低（比如status只有 'pending'/'done' 两种值） -
Extra出现Using where; Using index是理想状态；若只有Using index，说明是覆盖索引；若出现Using temporary或Using filesort，说明中间结果集太大或排序没走索引 - 中间表数据倾斜严重（比如一个用户收藏了10万商品，其他人平均只藏5个），优化器可能放弃走索引，直接选全表扫描——这时得考虑分库或业务层拆分
真正卡住性能的，往往不是JOIN语法本身，而是中间表那几行没被看见的索引定义和字段类型细节。上线前拿 EXPLAIN 对每个JOIN分支逐条过一遍，比事后调优省十倍力气。
