MySQL之谓词下推

MySQL之谓词下推

什么是谓词

在SQL中，谓词就是返回boolean值即true或者false的函数，或是隐式转换为boolean的函数。SQL中的谓词主要有 LKIE、BETWEEN、IS NULL、IS NOT NULL、IN、EXISTS

谓词下推的基本思想即：

将过滤表达式尽可能移动至靠近数据源的位置，以使真正执行时能直接跳过无关的数据。

传统数据库中的谓词下推：

在传统数据库的查询系统中谓词下推作为优化手段很早就出现了，谓词下推的目的就是通过将一些过滤条件尽可能的在最底层执行可以减少每一层交互的数据量，从而提升性能。例如下面这个例子：

select count(1) from A Join B on A.id = B.id where A.a > 10 and B.b < 100;

在处理Join操作之前需要首先对A和B执行TableScan操作，然后再进行Join，再执行过滤，最后计算聚合函数返回，但是如果把过滤条件A.a > 10和B.b < 100分别移到A表的TableScan和B表的TableScan的时候执行，可以大大降低Join操作的输入数据。优化后的语句如下：

select count(1) from (select *  from A  where a>10)A1 Join (select *  from B  where b<100)B1 on A1.id = B1.id;

无论是行式存储还是列式存储，都可以在将过滤条件在读取一条记录之后执行以判断该记录是否需要返回给调用者，在Parquet做了更进一步的优化，优化的方法时对每一个Row Group的每一个Column Chunk在存储的时候都计算对应的统计信息，包括该Column Chunk的最大值、最小值和空值个数。通过这些统计值和该列的过滤条件可以判断该Row Group是否需要扫描。另外Parquet未来还会增加诸如Bloom Filter和Index等优化数据，更加有效的完成谓词下推。

在使用Parquet的时候可以通过如下两种策略提升查询性能：

1、类似于关系数据库的主键，对需要频繁过滤的列设置为有序的，这样在导入数据的时候会根据该列的顺序存储数据，这样可以最大化的利用最大值、最小值实现谓词下推。

2、减小行组大小和页大小，这样增加跳过整个行组的可能性，但是此时需要权衡由于压缩和编码效率下降带来的I/O负载。

列式存储中的谓词下推思想

RF算法中，用了谓词下推思想。大小表进行broadcast hash join时，用小表的join列数据构建BloomFilter，广播到大表的所有partition，使用该BloomFilter对大表join列数据进行过滤。最后将大表过滤后得到的数据与小表数据进行hashJoin。

这个过程如下图：

这样的好处是：

• 在存储层即过滤了大量大表无效数据，减少扫描无效数据列的同行其他列数据IO
• 减少存储进程到计算进程传输的数据
• 减少hashjoin开销

如这个SQL:

select item.name, order.* from order , item where order.item_id = item.id and item.category = ‘book’

使用谓词下推，会将表达式 item.category = ‘book’下推到join条件order.item_id = item.id之前。再往高大上的方面说，就是将过滤表达式下推到存储层直接过滤数据，减少传输到计算层的数据量。

HIVE中的谓词下推（下推规则同样适用于SparkSQL）

​ Hive中的Predicate Pushdown简称谓词下推，简而言之，就是在不影响结果的情况下，尽量将过滤条件提前执行。谓词下推后，过滤条件在map端执行，减少了map端的输出，降低了数据在集群上传输的量，节约了集群的资源，也提升了任务的性能。

​ 具体配置项是hive.optimize.ppd，默认为true，即开启谓词下推

​ PPD规则：

​ 规则的逻辑描述如下：

• During Join predicates cannot be pushed past Preserved Row tables.

​ join条件过滤不能下推到保留行表中。

比如以下选择，left join中左表s1为保留行表，所以on条件（join过滤条件）不能下推到s1中

select s1.key, s2.key from src s1 left join src s2 on s1.key > '2';

而s2表不是保留行，所以s2.key>2条件可以下推到s2表中：

select s1.key, s2.key from src s1 left join src s2 on s2.key > '2';

• After Join predicates cannot be pushed past Null Supplying tables.

​ where条件过滤不能下推到NULL补充表。

比如以下选择left join的右表s2为NULL补充表所以，s1.key>2 where条件可以下推到s1：

select s1.key, s2.key from src s1 left join src s2 where s1.key > '2';

而以下选择由于s2未NULL补充表所以s2.key>2过滤条件不能下推

select s1.key, s2.key from src s1 left join src s2 where s2.key > '2';

关于join和where采用ppd的规则如下：

1、对于Join(Inner Join)、Full outer Join，条件写在on后面，还是where后面，性能上面没有区别；

2、对于Left outer Join ，右侧的表写在on后面、左侧的表写在where后面，性能上有提高；

3、对于Right outer Join，左侧的表写在on后面、右侧的表写在where后面，性能上有提高；

4、所谓下推，即谓词过滤在map端执行；所谓不下推，即谓词过滤在reduce端执行

注意：如果在表达式中含有不确定函数，整个表达式的谓词将不会被pushed，例如

select a.* from a join b on a.id = b.idwhere a.ds = '2019-10-09' and a.create_time = unix_timestamp();

因为unix_timestamp是不确定函数，在编译的时候无法得知，所以，整个表达式不会被pushed，即ds='2019-10-09'也不会被提前过滤。类似的不确定函数还有rand()等。

__EOF__

本文作者：等不到的口琴
本文链接：https://www.cnblogs.com/Courage129/p/14175363.html
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！