84669 orang belajar
152542 orang belajar
20005 orang belajar
5487 orang belajar
7821 orang belajar
359900 orang belajar
3350 orang belajar
180660 orang belajar
48569 orang belajar
18603 orang belajar
40936 orang belajar
1549 orang belajar
1183 orang belajar
32909 orang belajar
最近看高性能MySQl,里面是推荐把联合查询分解为多个简单的查询,既然是这样 那么还要联合查询干嘛?究竟是如何选择才是效率更高的选择呢?
简单的联合查询一般没有必要分解,这里所说的应该是比较复杂的联合查询,譬如联合查询3,4张表,如果查询较为复杂,涉及到分组,排序什么的,在运行时不能有效利用索引的。甚至有可能产生临时表。那效率就会比较差。而且不利于查询缓存。分解后针对每个简单的查询,数据库有查询缓存机制,会更加高效。对联合查询的语句尽量用explain分析一下有哪些问题?针对性的去改正。该分解的时候还是要分解。
select * from tb1 left join tb2 on tb1.id=tb2.tid where tb1.stat=1 and tb2.stat=1 and tb1.type=1
select * from ( select * from tb1 where stat=1 and type=1 ) as tb1 left join tb2 on tb1.id=tb2.tid where tb2.stat=1
上面是一个简单的案例, 其实我不是太明白你说的联合查询分解成多个简单的查询, 上面只能是我个人的一些优化(分解)方案而已(虽然也并不是每次都是这么用).
如果你所说的分解是将联表拆成很多个语句, 然后在代码中依次进行调用的话, 相信效率反而比联表还低, 每次连接数据库的 IO 开销肯定比一次联表来的多.
优化联表查询效率用一句话来说就是 用最少的正确数据进行关联
最少的数据, 就可以通过, 在表进行关联前, 提前将正确的数据提取出来, 避免关联时还有很多明显已经知道是错误的数据再去关联.
无论是何种 join 方式, 这种方式都能适用.
更多的提高效率方案也还有很多像是 where 的顺序, 字段类型, 索引 等等, 这个范围就很大了.
只要用好索引,联合查询没什么问题
简单的联合查询一般没有必要分解,这里所说的应该是比较复杂的联合查询,譬如联合查询3,4张表,如果查询较为复杂,涉及到分组,排序什么的,在运行时不能有效利用索引的。甚至有可能产生临时表。那效率就会比较差。而且不利于查询缓存。分解后针对每个简单的查询,数据库有查询缓存机制,会更加高效。对联合查询的语句尽量用explain分析一下有哪些问题?针对性的去改正。该分解的时候还是要分解。
上面是一个简单的案例, 其实我不是太明白你说的联合查询分解成多个简单的查询, 上面只能是我个人的一些优化(分解)方案而已(虽然也并不是每次都是这么用).
如果你所说的分解是将联表拆成很多个语句, 然后在代码中依次进行调用的话, 相信效率反而比联表还低, 每次连接数据库的 IO 开销肯定比一次联表来的多.
优化联表查询效率用一句话来说就是 用最少的正确数据进行关联
最少的数据, 就可以通过, 在表进行关联前, 提前将正确的数据提取出来, 避免关联时还有很多明显已经知道是错误的数据再去关联.
无论是何种 join 方式, 这种方式都能适用.
更多的提高效率方案也还有很多
像是 where 的顺序, 字段类型, 索引 等等, 这个范围就很大了.
只要用好索引,联合查询没什么问题