前言
null在数据中是一个很特殊的存在，我们实际经历多起生产事故，而且直接就带来直接的经济损失，这个值在实际使用的时候很容易被用错，今天我们来盘点一下null带来的坑吧。
对常见几种空的理解
比较结果错误
首先还是准备数据
create table tmp_null_test as select id,col from values(1,null) ,(2,'v2') ,(3,'v3') ,(null,'v4') t(id,col); select * from tmp_null_test; id col 1 \N 2 v2 3 v3 \N v4
最常见的就是我们期望获取null的值,比如我们很自然的想到列=null的情况
select * from tmp_null_test where col=null;
这个结果很诡异，实际上是查询不到结果的,我们直接看一下如果col=null是怎样的结果:
select id,col,col=null as pk from tmp_null_test; id col pk 1 \N \N 2 v2 \N 3 v3 \N \N v4 \N
特别的神奇,pk结果清一色\N,这样告诉我们获取null这样子是会错误的,null和任何结果比较其实都是无意义的。
怎么办呢？一般有下面些办法：
1、使用 is null
select id,col,col is null as pk from tmp_null_test; id col pk 1 \N true 2 v2 false 3 v3 false \N v4 false
2、使用 COALESCE/nvl函数把null转化掉，再进行过滤
select id,col,COALESCE(col,'')='' from tmp_null_test; id col _c2 1 \N true 2 v2 false 3 v3 false \N v4 false
select id,col,nvl(col,'')='' from tmp_null_test; id col _c2 1 \N true 2 v2 false 3 v3 false \N v4 false
大量null导致倾斜
null带来的倾斜主要有两种，一种是明确告诉你有null，再join我们倒是比较好发现，还一种是在隐式转换的时候带来了null这种很难发现，这个就是null阳谋和阴谋，不管那种情况，在数据体量比较大的时候，其实都会带来极差的性能。
阳谋
一般在数据内部有null的时候，我们直接用来做join，数据量大的时候就是很慢，甚至运行不出来，这种时候也是null的问题，这种情况需要看业务场景是否需要转化掉
阴谋
有一种情况存在，如下面图中的id,左边是字符串类型，右边其实是double类型,这种时候在做join的时候取值a,b的时候并不能转化成double,这个时候也会产生null
这种时候产生的null还不是直接产生的，是在做隐式转换的时候发生的，这个时候会导致异常，这种情况很难发现，我记得我们排查了大半年。后面发现问题之后，是需要提前把右边id转换成String类型，再做join。配上sql来说明:
第一次的样子：
select t1.id,t1.name,t2.name from table1 t1 join table2 t2 on t1.id=t2.id
实际转换路径如下：
要注意的是这个操作是隐式的，可以在日志上面看到，但是一般人不感知,这种时候会造成null
解决办法:
select t1.id,t1.name,t2.name from table1 join (selec cast(id as string) as id,name from table2) t2 on t1.id=t2.id
这种方式是主动把原来是double类型的id主动转换成字符串,带来的是下面的效果:
null占空间极小,改变了分发策略
在orc格式的存储时代，大量null的数据存在在一个很小的空间中，通过测试发现一个2M的文件，可以存储2亿行的数据,这种时候2m引擎会认为你是小文件，从而直接进行广播，结构就是导致Driver端的OOM,这种时候出现了很多起事故。
怎么解决呢？发现了直接禁止掉了广播了
后记
null需要小心使用，否则~
