多表left join 慢sql问题

bulingbuling^_^

已于 2023-02-27 19:25:11 修改

阅读量832

点赞数

分类专栏： mysql 文章标签： sql 数据库 mysql

于 2023-02-27 19:18:25 首次发布

mysql 专栏收录该内容

17 篇文章

订阅专栏

文章讨论了在MySQL8中，GROUPBY语句对查询性能的影响，特别是如何改变了HashJoin的使用。当添加GROUPBY时，查询速度提升，可能是因为优化器选择了不同的执行计划。解决方案包括使用GROUPBY和为关联字段添加索引来提高查询效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

作为个人记录，后续再填坑

a对p是1对多 ,p对llup 1对多

SELECT
    a.id,
    p.id,
    t1.id 
FROM
    liv_series_product a
    INNER JOIN liv_product p ON p.id = a.product_id
    LEFT JOIN ( 
        SELECT llup.id, llup.product_id, llup.room_id 
        FROM liv_live_user_product llup 
        WHERE llup.room_id = 1629055336439164930 
        
        ) t1 ON t1.room_id = 1629055336439164930 
    AND t1.product_id = p.id 
WHERE
    a.series_id = 1629025986310385665 
    AND p.on_off_status = 1 
GROUP BY
    a.product_id

0.8秒

加上GROUP BY llup.product_id 后0.1秒

加上grouby 后是生成了一个副表先执行了llup表。

MySQL8的 Hash Join

explain format = tree 查看，发现加了group by 的没有用上hash join

没加group by的如EXPLAIN下图第三行用上了 hash join，反而sql慢了

-> Table scan on <temporary>  (cost=0.01..4578.27 rows=366062)
    -> Temporary table with deduplication  (cost=73545.80..78124.06 rows=366062)
        -> Left hash join (llup.product_id = a.product_id)  (cost=36939.55 rows=366062)
            -> Nested loop inner join  (cost=551.86 rows=32)
                -> Filter: (a.series_id = 1629025986310385665)  (cost=327.45 rows=322)
                    -> Index scan on a using 商品_pk  (cost=327.45 rows=3217)
                -> Filter: (p.on_off_status = 1)  (cost=0.60 rows=0)
                    -> Single-row index lookup on p using PRIMARY (id=a.product_id)  (cost=0.60 rows=1)
            -> Hash
                -> Filter: (llup.room_id = 1629055336439164930)  (cost=44.35 rows=11379)
                    -> Table scan on llup  (cost=44.35 rows=11379)

有索引，不走hash join。

最后的解决办法有两种：