简单说说SQL中Join的使用

简单说说SQL中Join的使用_第1张图片

最近工作中,遇到了一起由于慢SQL引起DB CPU > 90% ,数据库hang住。。最终导致其他业务查询统统失败。

       细看下来是由于几张大表Join关联查询引起的,故障本身很常见,不过让我想到有必要讲讲如何规避Join的问题。

       以下的讨论都是基于数据库能力有限的前提下,否则后续的讨论就可以直接忽略了。


首先,我们来谈谈SQL Join的使用场景


1)如果系统存在


高并发、分布式

业务逻辑简单

数据的一致性要求不高

允许延迟读


那么建议在SQL中少使用Join。减少join的目的是在这类业务场景下,除了直观地降低了高并发状态下的资源消耗外,更大的好处是降低了业务之间的耦合,增加了扩展性。服务就可以拆分成多个微服务和多个数据库,便于在一部分负担过重时进行增配;或者直接改为使用缓存等等。


2)如果系统存在


低并发、频繁复杂数据写入

CPU密集而非IO密集

业务逻辑通过数据库处理甚至包含大量存储过程

对一致性与完整性要求很高的系统

需要大量的报表和统计


那么是需要数据库Join的,可以说是无法避免Join。比如部分金融业务、财务系统、企业应用之类,复杂join也是不可避免的,不仅要写,还要写好,才能发挥数据库最大的功用。



对于情况1,我们有以下几种常见的方案来替代Join:


1. 分多次select取不同表的数据,然后在应用代码里做Join;

2. 各自存数据的同时,做一张宽的冗余表,从宽表里取查询数据;

3. 需要Join的数据保存在缓存中(如redis),缓存可以使用主动式(数据修改时更新缓存)或被动式(缓存删除后,读取时才加载);

4. 从独立的用户API接口进行读取。和方法1类似,在代码里做聚合。



对于情况2, 我们的目标是优化Join,提升对应的性能,常见的方案如下:


1.用小结果集驱动大的结果,目的是为了尽可能减少Join语句中的NestedLoop的循环总次数,比如,当两个表(表A和表B)Join的时候,如果表A通过WHERE条件过滤后有10条记录,而表B有20条记录。如果我们选择表A作为驱动表,也就是被驱动表的结果集为20,那么我们通过Join条件对被驱动表(表B)的比较过滤就会有10次。反之,如果我们选择表B作为驱动表,则需要有20次对表A的比较过滤。


2.保证Join语句中被驱动表上Join条件字段已经被索引,保证被驱动表上Join条件字段已经被索引的目的,正是针对上面第1点的考虑,只有让被驱动表的Join条件字段被索引了,才能保证循环中每次查询都能够消耗较少的资源,这也正是优化内层循环的实际优化方法。


3.增大Join_Buffer_Size的大小,MySQL在完成某些join需求的时候(all row join/all index /scan join)为了减少参与join的“被驱动表”的读取次数以提高性能,需要使用到join buffer来协助完成join操作。当join buffer 太小,MySQL不会将该buffer存入磁盘文件而是先将join buffer中的结果与需求join的表进行操作,然后清空join buffer中的数据,继续将剩余的结果集写入buffer中,如此往复,这势必会造成被驱动表需要被多次读取,成倍增加IO访问,降低效率(执行计划中如果现实using join buffer)。如果join语句不是很少的话,个人建议可以适当增大join_buffer_size到1MB左右,如果内存充足可以设置为2MB。


最后一点总结就是,数据不大的时候怎么做都行,就按数据库规范设计最好。数据量大的时候,为了性能就只能牺牲一些规范了。任何的规范都是在特定情况下的某种妥协,脱离了这个环境,就不一定成立了。



扫描二维码或手动搜索微信公众号【架构栈】: ForestNotes

欢迎转载,带上以下二维码即可

                         640?wx_fmt=jpeg


点击阅读原文”,所有【架构栈】近期的架构文章汇总

↓↓↓

你可能感兴趣的:(简单说说SQL中Join的使用)