单表查询和多表连接查询哪个效率更快?

这段时间在做项目的过程中,遇到一个模块,数据之间的联系很复杂,在建表的时候就很纠结,到底该怎么去处理这些复杂的数据呢,是单表查询,然后在业务层去处理数据间的关系,还是直接通过多表连接查询来处理数据关系呢?

通过查阅资料和阅读博客,有以下两个回答:

一、《高性能mysql》中的回答

很多高性能的应用都会对关联查询进行分解。简单地,可以对每个表进行一次单表查询,然后将结果在应用程序中进行关联。例如,下面这个查询:

select * from tag

join tag_post on tag_post.tag_id=tag.id

join post on tag_post.post_id=post.id

where tag.tag=’mysql’;

可以分解成下面这些查询来代替:

Select * from tag where tag=’mysql’;

Select * from tag_post where tag_id=1234;

Select * from post where id in(123,456,567,9989,8909);

到底为什么要这样做?

咋一看,这样做并没有什么好处,原本一条查询,这里却变成了多条查询,返回结果又是一模一样。

事实上,用分解关联查询的方式重构查询具有如下优势:(高并发、高性能的应用中,一般建议使用单表查询)
1. 让缓存的效率更高。许多应用程序可以方便地缓存单表查询对应的结果对象。另外对于MySQL的查询缓存来说,如果关联中的某个表发生了变化,那么就无法使用查询缓存了,而拆分后,如果某个表很少改变,那么基于该表的查询就可以重复利用查询缓存结果了。

2. 将查询分解后,执行单个查询可以减少锁的竞争。

3. 在应用层做关联,可以更容易对数据库进行拆分,更容易做到高性能和可扩展,很多高性能的应用都会对关联查询进行分解。

4. 查询本身效率也可能会有所提升,这个例子中,使用 IN() 代替关联査询,可以让 MYSQL 按照 ID 顺序进行査询,这可能比随机的关联要更高效。。

5. 可以减少冗余记录的查询,在应用层做关联査询,意味着对于某条记录应用只需要查询一次,而在数据库中做关联查询,则可能需要重复地访问一部分数据。从这点看,这样的重构还可能会减少网络和内存的消耗。。

6. 更进一步,这样做相当于在应用中实现了哈希关联,而不是使用MySQL的嵌套环关联,某些场景哈希关联的效率更高很多。

7. 单表查询有利于后期数据量大了分库分表,如果联合查询的话,一旦分库,原来的sql都需要改动。

8. 上次看到某个CTO技术分享,公司规定底层禁止用join联合查询。数据大的时候确实慢,所以在数据量不大的情况下,两种方式的查询都没什么明显的差别,使用多表连接查询更方便。但是如果在数据量达到几十万、几百万甚至上亿的数据,或者在一些高并发、高性能的应用中,一般建议使用单表查询。。

9. 联合查询或许确实快,但是mysql的资源通常比程序代码的资源紧张的多。

二、其他的一些回答

情景假设:假设网站有一个公司库版块,我想搜索某城市的所有公司。

数据表:tbl_company (t1)、 tbl_city (t2)。

例1: t1表中存cityid 根据id做表连接查询 select * from t1 inner join t2 on t1.cityid=t2.cityid;

例2: t1表中存cityName 用户前台点击上海市,则把上海市的id传到后台(不考虑传cityName),根据id查出cityName select cityName from t2 where cityid= #{cityid};, 然后 select * from t1 where cityName = #{cityName};

两者区别:例1中只做了一次表关联查询,例2中分别做了两次单表查询。

考虑到数据量大,多表连接查询会影响查询效率所以都优化为单表查询。 TP:以上是在不使用索引的情况下

请问哪种效率会更高些?

答:sql优化与业务也有关系,这条语句的查询会不会频繁,要不要考虑2次连接带来的开销,如果这些都不用考虑的话,都没有索引的情况下,感觉相差不大,2应该略优于1。

数据没有特别大的情况还是级联查询快。

对于传统的数据库涉及来说, 尽可能减少数据库查询次数.

BUT, 1. mysql都对处理连接/断开连接, 回复小而简单的 查询是非常快的; 2.现在的网络已经非常快了. 所以多个小的查询对mysql来说可能更快一些.

最后, 大神也没有结论哪个更好. 呵呵, 其实整本书都明确表达一个意思, 测试测试! 做benchmark! 对于自己的数据环境, 把两种方式都测试一下. 用数据说话.

三、总结

个人建议还是用单表查询!在应用层做数据之间的关联会更好!

  • 2
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: MySQL的内连接和左连接效率问题不是绝对的,它们的效率取决于具体的查询语句和结构。在某些情况下,内连接可能更快,而在其他情况下,左连接可能更快。一般情况下,内连接效率比左连接更快,因为内连接只返回两个之间匹配的行,而左连接需要返回左的所有行和匹配的右的行,如果右中没有匹配的行,则返回NULL值。但是在某些情况下,使用左连接可以避免查询中的重复数据,提高查询效率。因此,选择使用内连接还是左连接应该根据具体的需求和查询条件来决定。 ### 回答2: MySQL的内连接和左连接效率并没有绝对的答案,因为它们的效率取决于具体的数据库设计、索引使用和查询需求等多个因素。 内连接是通过匹配两张之间的共同数据来返回结果。它仅返回匹配的行,如果之间没有匹配的数据,那么将不会返回任何结果。由于内连接只返回匹配的行,所以它通常是比较高效的。如果在连接的列上存在索引,那么内连接效率将更高,因为索引能够加速数据的查找和匹配过程。 左连接是将左中的所有数据都返回,同时匹配右中的数据。如果右中没有匹配的数据,那么结果中对应的字段就会显示为NULL。左连接会返回较多的数据,所以在一些情况下可能会比较耗时。但是如果查询需要获取左的全部数据,无论是否存在匹配的右数据,那么左连接是更合适的选择。 总的来说,内连接在某些具体的场景下可能比左连接更高效,因为它只返回匹配的数据。但是在其他情况下,左连接可能更适合获取完整的数据集。不同的查询需求和数据库设计都会对效率产生影响,因此在实际应用中,我们需要根据具体情况选择合适的连接方式。 ### 回答3: MySQL的内连接和左连接效率取决于具体的查询和数据情况。一般情况下,内连接效率更高。 内连接是通过比较两个之间的关联字段,并返回满足条件的记录。它只返回两个关联字段匹配的数据,因此它们通常需要比较少的数据量,从而提高查询效率。 左连接是根据左的记录,联接右的记录,并返回所有左的记录以及满足关联条件的右记录。这意味着左连接可能返回大量的数据,尤其是右中含有大量匹配记录时。因此左连接在某些情况下可能会降低查询效率。 然而,具体的情况可能因查询条件、数据量和结构等因素而异。如果左和右的数据量相似,内连接和左连接效率可能没有明显差异。而如果右中的匹配记录非常少,左连接可能会在一定程度上更快,因为它不需要进行大量的数据匹配。 总的来说,内连接和左连接效率取决于实际情况,通常情况下内连接更快,但在特定情况下左连接也可能具有更高的效率。对于具体的查询,可以通过分析执行计划和性能测试来确定最佳的连接方式。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值