Hive sql写法问题导致运行慢问题合集（一）

1.     over(partition by order by)语法partition by和order by后字段一致

现象:

mr任务运行缓慢

原因：

partition by order by 语法含义为分组后排序组内数据

其中的排序算法使用的为快速排序，partition by和order by字段一致会导致分区内全为相同数据，排序性能恶化严重，且p 与o字段相同排序无意义

解决方法：

1.partition by与order by字段修改为不同字段

2.删除order by

2.     join中非常规join on写法

现象:

mr任务运行缓慢

原因：

未使用标准a join b on a.xx=b.xx形式进行表关联，而是写成a,b where a.xx=b.xx形式

会笛卡尔积导致运行速度缓慢

该问题可直接打执行计划进行确认，该类sql join的task中无key值

解决方法：

1.修改为标准join on

2.部分场景在开启hive.cbo.enable为true时a,b where a.xx=b.xx形式执行计划可转化为非笛卡尔积

是否解决可以再打执行计划确认keys有值则解决，例如下图

3.     视图中多表union all，视图外指定分区

现象：

mr任务运行缓慢

原因：

视图定义为多表Union all情况下，在视图定义中的表分区数据类型不同时，在视图外指定分区条件不会下推条件到视图中的表里，导致视图定义中的表在执行sql时出现全表扫描

视图示例如下：

Sql示例如下（例如tb_1-tb_4的分区条件都为cp）

Select * from view_1 where cp=xxx;

确认全表扫描的方法如下

可以看执行计划中是否有分区筛选条件，以及统计信息是否很多，有筛选且统计信息打印很多则为未下推

未下推图：

下推图：

解决方法：

1. 视图定义中的表设置相同分区字段类型
2. 视图中指定分区条件

修改后是否解决可同样通过执行计划查看是否有分区筛选条件，以及统计信息是否很多

4.join on 条件中有or

现象：

mr任务运行缓慢，sql示例如下

原因：

join on 条件中有or，join时会没有key导致产生笛卡尔积

该问题可直接打执行计划进行确认，该类sql join的task中无key值

解决方法：

整改sql，可以使用union

是否解决可以通过打执行计划进行确认，有key则解决，例如下图

5.数据中重复数据多，join慢

现象：

mr任务运行缓慢

原因：

join的两表关联的key值字段存在大量重复数据，join产生类似笛卡尔积，导致写出数据膨胀，任务运行慢

解决方法：

查询两表join on条件字段值的分布情况，可以将大key提取出来进行单独处理，结果集使用union all进行拼接

6.sql过于复杂,例如层层嵌套的套娃式sql

现象：

hivesql编译慢10小时以上，sql类似下图

原因：

sql过于复杂，hiveserver无法编译

解决方法：

整改sql