欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  后端开发

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

程序员文章站 2022-04-23 23:41:26
...
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等)