关于SQL优化解决InceptorSQL慢的一些思路

星环科技TDH社区版

已于 2024-06-26 18:14:45 修改

阅读量644

点赞数 21

分类专栏：产品使用教程性能优化文章标签： sql 数据库分布式数据库架构大数据性能优化

于 2024-06-25 09:00:00 首次发布

本文链接：https://blog.csdn.net/tiancaidddddd/article/details/139927987

版权

产品使用教程同时被 2 个专栏收录

10 篇文章 0 订阅

订阅专栏

性能优化

2 篇文章 0 订阅

订阅专栏

一、SQL优化的几点建议

减少数据访问，减少扫描的数据量；
减少中间结果量，减少网络传输或磁盘访问；
减少交互次数；
改进算法，业务优化，减少JOIN次数，减少服务器CPU 开销；
优化数据分布（需要了解ER模型），通过分区、分桶、排序、索引等手段，把业务相近的数据放在一起。

二、优化场景示例

1）避免使用 select * 来获取所有字段，即使需要全部字段最好是枚举出所有的字段。

不建议这么写：

SELECT * from table;

2）在分布式数据库中，不建议全表进行order by 排序，可以使用sort by进行局部排序，如果进行全表排序，最好加上limit，否则进行时间会很长。

3）尽量避免使用循环。频繁的操作，第一效率低，第二如果是更新操作会引起事务表的频繁合并，甚至造成表不可用。

For: var in ids[] do begin
   Select XX FROM table_name where id = :var;
End;

改写为下面的语句，这样就把多次交互压缩在一次访问中完成，加速任务的完成：

SELECT XXX FROM table_name  WHERE id IN ids[];

4）表中保存的数据要符合规范，比如去除字符串两边的空白字符，可以避免在where筛选的时候再进行处理。

5）谓词下推。是指将外层的查询块的WHERE 查询移入包含的较低层的查询快，从而更早的进行数据过滤，减少参与运算与传递的数据量。原则上，推的越往前越好。可以通过查看执行计划来检查谓词是否被成功下推。

示例：

SELECT COUNT(1) FROM store_sales ss, item I WHERE ss.item_sk = i.item_sk AND i.manufact_id = 436;

改为：

SELECT COUNT(1)  FROM store_sales ss, (SELECT i.item_sk FROM item WHERE i.manufact_id = 436) ii WHERE ss.item_sk = ii.item_sk;

6）尽量避免大表与大表直接JOIN，执行之前要分析一下SQL，如果有小表，先用小表或者是过滤率较高的表过滤大表，即尽可能先做与小表有关的JOIN，再使大表参与进来（前提是JOIN的满足交换律）。JOIN的原则是尽量减少中间结果。

7）大表与小表JOIN 时，需采用MapJoin。执行MapJoin 时须重点关注JOIN的顺序和过滤后小表的行数，一般小表的数据量不超过20万条。Mapjoin基本思想是将小表的数据广播给每个Executor，Executor 拿到数据后建立一张小表的Hash 表，Executor 读取本地大表的数据块，根据Join Key 查小表的Hash 表，再进行JOIN，这样也是为了减少Shuffle过程产生的数据量。

8）“小表JOIN 大表”也可以考虑使用lookup join。这里的“小表”不仅仅指该表的数据量很小，也可以是一张大表，但是这张大表后面的过滤条件，加上利用大表自身所具备的Global Index（全局索引）可以快速检索出少量数据。

9）使用UDF或者函数时，避免使用过多的函数，如果条件允许可以封装成一个UDF会更好。

10）在使用模糊匹配时，尽量避免在开头使用，这样只能全表扫描，对于有索引的表也利用不上索引。

示例：

Select xxx from table where name like %transwarp%

11）按照星环推荐的方式进行分区分桶，对于不同的场景使用不同存储的表，比如交互式统计分析类场景最好使用Holodesk，离线批处理加工优先使用ORC，而快速查询业务Hyperbase 更合适，若涉及到比较多的字段的查询以及模糊查询，使用Elastic Search（ES）更好。

三、Inceptor SQL慢的排查思路

1）选取几个有典型代表的SQL，分步执行（可以从最内层，一层层的加，找出那层比较慢），不要直接执行所有的语句，一是因为等待结果的耗时很长，二是因为增加了分析的困难度。

2）查看4040界面，观察是否存在这样两种异常：1. Task 数目十分庞大；2.某些Stage 运行速度很慢。

3）针对以上发现的异常，进行性能优化。检查和优化的过程大体分为以下五个方面：

A. 资源使用。结合top、free、iotop等命令查看系统的资源是否比较紧张；
B.分析数据。获取每个表的各行各列的特性，比较分析是否存在记录行数很大的表、表与表的特点差异和记录条目数数量级的差距，以及数据分区分桶是否合理等；
C.分析执行计划。明确是否应该用MapJoin，是否应调整JOIN 顺序，是否需要谓词下推。
D.分析过滤率。计算过滤率，核对JOIN 顺序并做出调整，先JOIN 数据量少过滤率高的表。
E. 分析进程的内容信息。对慢的任务，分析反属进程的jmap、jstack等信息。

按照以上方法不断优化、迭代，直至得到满意效果为止。