一.第一个解答来源于《高性能Mysql》中的回答mysql
不少高性能的应用都会对关联查询进行分解。简单地,能够对每一个表进行一次单表查询,而后将结果在应用程序中进行关联。例如,下面这个查询:sql
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’;post
Select * from tag_post where tag_id=1234;性能
Select * from post where id in(123,456,567,9989,8909);测试
到底为何要这样作?
咋一看,这样作并无什么好处,本来一条查询,这里却变成了多条查询,返回结果又是如出一辙。
事实上,用分解关联查询的方式重构查询具备以下优点:(高并发、高性能的应用中,通常建议使用单表查询)
1. 让缓存的效率更高。
许多应用程序能够方便地缓存单表查询对应的结果对象。另外对于MySQL的查询缓存来讲,若是关联中的某个表发生了变化,那么就没法使用查询缓存了,而拆分后,若是某个表不多改变,那么基于该表的查询就能够重复利用查询缓存结果了。
2. 将查询分解后,执行单个查询能够减小锁的竞争。
3. 在应用层作关联,能够更容易对数据库进行拆分,更容易作到高性能和可扩展。
4. 查询自己效率也可能会有所提高。
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! 对于本身的数据环境, 把两种方式都测试一下. 用数听说话.
总结:建议仍是用单表查询!