V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
857681664
V2EX  ›  程序员

MySQL 的 inner join 顺序是否会影响最后查询的性能

  •  
  •   857681664 ·
    zshnb · 177 天前 · 1431 次点击
    这是一个创建于 177 天前的主题,其中的信息可能已经有所发展或是发生改变。

    假设有表 a ( 100 条)表 b ( 50 条) 然后是以下 2 条 sql 语句

    select *
    from a
    inner join b
    ---
    select *
    from b
    inner join a
    

    对于上面 2 条 sql,最后执行的速度会有区别吗?我记得 MySQL 的 join 是 nested loop 实现的,个人感觉应该没有什么区别吧。

    12 条回复    2022-08-05 14:37:06 +08:00
    liprais
        1
    liprais  
       177 天前 via iPhone
    不会
    7911364440
        2
    7911364440  
       176 天前
    用小表做驱动表可以减少被驱动表的访问次数,没有其他过滤条件的话还是 b 做驱动表好些
    zed1018
        3
    zed1018  
       176 天前
    8 以后有 hash join
    enjoychen0318
        4
    enjoychen0318  
       176 天前
    上面的两种写法,mysql 好像都会帮你优化成小表驱动大表的
    enjoychen0318
        5
    enjoychen0318  
       176 天前
    驱动表对执行速度的影响可以看丁奇《 mysql45 讲》的第 34 讲
    iXInbo
        6
    iXInbo  
       176 天前
    主要是小表驱动大表,如果反了可能会影响性能
    lazyfighter
        7
    lazyfighter  
       176 天前
    我觉得 mysql 没必要设计的这么 low ,优化器应该会优化的
    JaguarJack
        8
    JaguarJack  
       176 天前
    优化器回优化的,不用管
    857681664
        9
    857681664  
    OP
       176 天前
    @enjoychen0318
    @7911364440
    @iXInbo
    如果单纯是 inner join 的话,感觉驱动表大小不会影响最后的结果吧,nested loop join 下,外面 for50 次,里面 for100 次跟外面 for100 次,里面 for50 次在 cpu 运算上好像没有区别,在数据量比较小的例子下,io 层面也是一样的消耗
    iPisces77
        10
    iPisces77  
       176 天前
    优化器会优化,但还是要查一下执行计划
    iseki
        11
    iseki  
       176 天前 via Android
    现在数据库基本都是 CBO 的,查执行计划吧,猜有点困难呐
    iXInbo
        12
    iXInbo  
       174 天前
    一般这种优化都是次数上去了才会有明显的变化;比如外面 5000 次和 1000 次的对比,甚至几万几千万,
    可能原本几毫秒的差距会被放大成几秒和几十秒;
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   实用小工具   ·   933 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 38ms · UTC 01:33 · PVG 09:33 · LAX 17:33 · JFK 20:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.