本文参考官网, 官网关于explain的链接: http://phoenix.apache.org/explainplan.html

小衲对Phoenix学习还不是很深入, 先发一个初版的, 基本上是照搬官网的, 后续学习深入了再来补充修改.

1. 简介

简单来说, 就是通过在SQL前面加上 explain命令, 来查看这个SQL准备要做些什么.

命令示意:

正常SQL:
select a from my_table;

查看执行计划SQL:
explain select a from my_table;

2. 执行计划会告诉我们什么?

1. 将要执行的所有HBase查询
2. 预估要扫描的字节数
3. 预估要遍历的行数
4. 收集上述预估信息的时间
5. 每次扫描会使用哪个HBase表
6. 在客户端与服务端分别执行了哪些操作（排序，合并，扫描，limit限制）

3. 性能良好的执行计划应该满足以下条件:

(如果不满足, 说明你的SQL有问题, 要想办法修改)

1. 除了必要的客户端操作外, 大多数操作应该尽可能的都在服务端, 因为服务端是一个集群, 处理速度快, 而客户端只是一个单独的机器.

2. 尽可能使用RANGE SCAN或SKIP SCAN而不是TABLE SCAN, 也就是最好不要出现全表扫描

3. 查询SQL中, where条件最好是包含所有的主键, 最次也要包含前几个,  前几个不能省略, 否则会大大的降低性能, 出现全表扫描的情况.

4. 最好使用索引查询, 索引可以明显的提升查询速度

5. 如果你的SQL包含了索引字段, 但是Phoenix协处理器并没有在执行SQL的时候使用索引, 可以强制指定索引, 语法为: 

 SELECT /*+ INDEX(my_table my_index) */ v2 FROM my_table WHERE v1 = 'foo'

4. 执行计划内容解释

• AGGREGATE INTO ORDERED DISTINCT ROWS

        aggregates the returned rows using an operation such as addition. When ORDERED is used, the GROUP BY operation is applied to the leading part of the primary key constraint, which allows the aggregation to be done in place rather than keeping all distinct groups in memory on the server side.

使用诸如加法之类的操作聚合返回的行。使用ORDERED时，GROUP BY操作应用于主键约束的前导部分，这允许聚合在适当的位置完成，而不是将所有不同的组保留在服务器端的内存中。

使用有GROUP BY子句的聚合函数将结果聚合为不同的多行

• AGGREGATE INTO SINGLE RO

使用没有GROUP BY子句的聚合函数将结果聚合为单行。例如，count（）语句返回一行，其中包含与查询匹配的总行数。

• CLIENT

操作将在客户端执行。在服务器端执行大多数操作的速度更快，因此您应该考虑是否有办法重写SQL查询语句, 以便让更多的操作都在服务器执行, 提高查询效率.

• FILTER BY 表达式

仅返回与表达式匹配的结果, 就是过滤器

• FULL SCAN OVER tableName

全表扫描, 出现了这种情况, 就要修改SQL了,  不然性能会很慢

• INNER-JOIN

该操作将在满足连接条件的行上连接多个表

• MERGE SORT

对结果执行合并排序

• RANGE SCAN OVER tableName [ … ]

方括号中的信息表示查询中使用的每个主键的开始和停止。

• ROUND ROBIN

when the query doesn’t contain ORDER BY and therefore the rows can be returned in any order, ROUND ROBIN order maximizes parallelization on the client side.

当查询不包含ORDER BY并因此可以按任何顺序返回行时，ROUND ROBIN命令最大化客户端的并行化。

• x-CHUNK

执行SQL的线程数。最大并行度仅限于线程池中的线程数, 是一个客户端配置, 和hbase没有直接关系。最小并行化对应于表在扫描的开始行和停止行之间具有的region数量, 也就是一个region至少有一个scan扫描。这个并行度还和 guidepost width 有关,  如果路标宽度为100M, 也就意味着, 1G的region, 会有10个扫描并行执行

简单说, chunk数就是scan数

• PARALLEL x-WAY

表示SQL执行期间最终将会合并成多少个并行度,  经测试, 我感觉应该是每个region的scan都会合并成一个返回结果

简单说就是, chunk 个 scan 并行执行完, 结果将保存到 way 个 List集合中, 我们获取结果就是遍历way个List集合. 

其实在简单说, way其实没啥用, 和并行度没啥关系, 只是汇总结果的时候定义集合的大小.

• SERIAL

一些查询以串行方式运行。例如，单行查找或在前几个主键上过滤的查询，并将结果限制在可配置的阈值以下。

• EST_BYTES_READ

预估扫描的总字节数

• EST_ROWS_READ 

预估扫描的总行数

• EST_INFO_TS 

收集统计信息的时间点(毫秒), 其实就是时间戳