当前位置:Gxlcms > PHP教程 > 请大神来讲讲数据库数据量大的时候避免用join查询的方式来做数据库查询优化

请大神来讲讲数据库数据量大的时候避免用join查询的方式来做数据库查询优化

时间:2021-07-01 10:21:17 帮助过:118人阅读

boss说平时查询数据量大的数据尽量避免用join 宁可一次将一张表的数据查出来再用这些数据去做查询 也不要用过多的使用join 尽量分成多次查询来做 ,请大神来讲讲这其中的sql优化

回复内容:

boss说平时查询数据量大的数据尽量避免用join 宁可一次将一张表的数据查出来再用这些数据去做查询 也不要用过多的使用join 尽量分成多次查询来做 ,请大神来讲讲这其中的sql优化

如果用了关系型数据库,用表的join是很自然的做法,除非一些特例:

  1. sql语句太复杂,或统计信息不准确,造成数据库生成的执行计划不正确,导致运行效率低下,且短时间没办法改写sql

  2. 数据量特别大(至少过亿),数据库负载成为整个系统的性能瓶颈,在架构设计的时候就规定了不用数据库本身的表连接功能。

  3. 使用了ORM框架,对于关联对象默认会使用N+1查询的方式,如果数据量不是特别大,加上有缓存功能,效率并不低。

所以一般情况下,用数据库的join功能,比自己多次取数据做关联效率要高,否则一张大数据量表,但是传递到PHP中,就要花费很长的时间。

sql优化最基本的原则,就是让数据库尽早、高效率的过滤数据,避免无效的运算,具体的手段比较多,需要根据不同的数据库来确定实现方案。

请自行explain之。

这要看你数据库链接是不是长链接了,如果配置为长链接的话还好一点,不过要join的时候可以首先通过where或者其他方法缩减你的主表,不要一股脑的拉起来,这样的话性能会好很多。但是还是具体问题具体分析吧,跑一遍就有结果了哇。不过如果不是长链接的话估计连表会快一点。

分成多次查询的原因是因为:无论是join还是子查询,mysql优化器都会对sql进行优化(子查询就会自作聪明办坏事,join偶尔也会)
所以一条一条写,自己可以把握

join方式其实挺好,主要是索引把握起来不是那么的得心应手,容易出现问题。

所以你们boss直接说join不要用于大数据。

而分别查的原因:比如我拿到对应这边的主键id,再到另外表去查,效率肯定是高得不要不要的。

一句话:越简单的查询效率越高

真不明白数据量大的情况下join了会导致性能低下,如果数据量大了单独查询某个表就几百兆上G,加载到程序就花费好长时间

  1. 索引会加快查询速度

  2. 利用缓存(memchache等)

人气教程排行