MySQL多对多关联下EXISTS与IN性能波动大如何优化？

你遇到的耗时波动本质是两种查询的执行计划适配场景互斥：

• WHERE IN 方案：先查出所有符合条件的post_id，再关联posts表过滤、排序。匹配到的post_id量级小的时候速度极快，但如果匹配到几千上万条post_id，全量排序的成本会指数级上升，就是你遇到的几十秒延迟的场景。
• EXISTS 方案：按post_date倒序扫posts表，每扫一条就去关联表校验是否属于目标站点，找到6条就终止。如果符合条件的最新内容多，扫几条就能拿到结果速度极快；但如果目标站点的内容很少、且都分布在较早的时间，需要扫上千上万条posts才能凑够6条，就会变慢。

不需要动态判断数据量选查询方式，改用INNER JOIN写法+覆盖索引优化即可适配99%的场景：

1. 索引优化 #

先清理冗余索引、新增覆盖索引，避免回表开销：

• 删掉post_websites表上冗余的website_id_index，你的主键已经是(website_id, post_id)，前缀匹配即可满足website_id的过滤需求，不需要单独建索引。
• 把posts表的id_post_date_status_deleted_at索引替换为联合索引(status, deleted_at, post_date, id, title, description)，该索引完全覆盖你的查询条件、排序规则、返回字段，查询时不需要回表读行数据。

2. SQL查询改写 #

改用INNER JOIN写法，让MySQL优化器可以根据数据量自动选择最优执行计划：

SELECT DISTINCT p.*
FROM posts p
INNER JOIN post_websites pw ON p.id = pw.post_id
WHERE 
    pw.website_id IN (12054, 19829, 2258, 253)
    AND p.status = 1
    AND p.deleted_at IS NULL
ORDER BY p.post_date DESC
LIMIT 6;

加DISTINCT是为了避免同一个post绑定多个目标站点时出现重复结果。

3. 对应Eloquent写法 #

$news = Post::select(['posts.title', 'posts.description'])
    ->join('post_websites', 'posts.id', '=', 'post_websites.post_id')
    ->whereIn('post_websites.website_id', $sites)
    ->where('posts.status', 1)
    ->whereNull('posts.deleted_at')
    ->orderBy('posts.post_date', 'desc')
    ->distinct()
    ->limit(6)
    ->get();

改写后的查询会自动适配两种场景：

• 目标站点匹配的post少：优化器会优先查post_websites拿到所有符合的post_id，再关联posts表取数排序，和IN方案效率一致。
• 目标站点匹配的post多：优化器会优先按post_date倒序扫posts的覆盖索引，找到6条符合关联条件的就终止，和EXISTS方案效率一致。

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