数据量大查询效率优化的疑惑

[cobbage]

select * from a left join c left join b on a.bcode=b.code where b.xxid in(1,2,3);

a 表数据量比较大,实际数据有三张大表这样 union all

我是这样优化的（因为前端传的是 xxid,我吧 xxid 先转 bcode 查出来直接塞到条件里 效率确实提高了。）

select * from a left join c left join b on a.bcode=b.code where a.bcode in(11,22,33);

b 表的量在 1k 多有（ code xxid 都建了索引的），a 表百万到千万；

查询内容不变为什么这样优化后数据效率会提高

[sagaxu]

看实际执行计划 EXPLAIN ANALYZE ，对比两者区别。

DB 查询优化器，一般基于统计数据做预估，经常失真选择错误的执行路径或者选错索引。

[orioleq]

这不显而易见的结果么，先直接过滤最大的表数据获得一个相对小的数据集再跟别的小表做关联，内存上使用都要小很多

[netnr]

浅析，不考虑优化器，a 表 未过滤进行 join 产生中间表很大，先过滤再 join 就仅仅是你要的三条数据，
减少了 (a 表数据量减 3) 的无用功 join

[MeiJM]

解析顺序是从 form 的表开始，所以 form 的表数据量会影响查询效率

[ilucio]

这么理解比较好

[ilucio]

select * from ( select * from a where bcode in (11,22,33)) t left join c left join b on t.bcode=b.code
这样表的数据就小很多了

[PopRain]

@MeiJM 解析顺序并不等于执行顺序，再说，这个“解析”要看你怎么理解了

[MeiJM]

@PopRain 是的。 说的不对。 执行顺序依赖数据库查询优化。