[Phoenix] 十一、查询计划详解

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云原生多模数据库 Lindorm,多引擎 多规格 0-4节点
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
简介: 数据库的使用中了解其查询计划的构成,是进行查询性能调优的必要条件。本文将详细介绍Phoenix的查询计划语法、组成结构,以及一些注意事项

一、概要

在数据库中,执行计划就是表示一条SQL将要执行的步骤,这些步骤按照不同的数据库运算符号(算子)组成,具体的组成和执行方式由数据库中的查询优化器来决定。换而言之,执行计划决定了SQL的执行效率。在数据库的使用中了解其查询计划的构成,是进行查询性能调优的必要条件。本文将详细介绍Phoenix的查询计划语法、组成结构,以及一些注意事项。

二、查询计划

1. 基本说明

在phoenix中,查询计划能告诉我们如下的信息:

  • 将要扫描的CHUNK数量
  • 客户端并发线程数量
  • 执行模式(并行或串行)
  • 查询过滤字段或者扫描范围
  • 将会查询的表名
  • 估算扫描数据bytes大小(依赖stats信息)
  • 估算扫描数据量大小(依赖stats信息)
  • 估算数量bytes大小和数据量时间
  • 操作符被执行在客户端或者服务端
  • 涉及的查询operations(sort、filter, scan, merge, join, limit等)

2. 语法

explain [select... | upsert ... select | delete...] 

explain语法示例如下:

explain SELECT host FROM PTSDB WHERE host IN ('a','b');

explain UPSERT INTO t1 SELECT id FROM t2 ORDER BY K1, V1;

3. 如何选择最优查询计划

检查查询计划是否最优,核心有以下几点可以作为参考:

  1. 尽量避免出现FULL SCAN,尤其对于不走索引表的单表查询,不应该出现FULL SCAN
  2. 执行模式尽可能使用并行(某些情况一定是串行的执行模式)
  3. 尽可能将对应表的过滤条件或计算下推到server端
  4. 尽可能使用覆盖索引,生成不需要回查数据表的查询计划

三、查询计划详解

1. 操作符说明

  • UNION ALL: 表示union all查询,操作符后面接查询计划中涉及查询的数量
  • AGGREGATE INTO SINGLE ROW: 没有groupby语句情况下,聚合查询结果到一行中。例如 count(*)
  • AGGREGATE INTO ORDERED DISTINCT ROWS:带有group by的分组查询
  • FILTER BY expression: 过滤出符合表达式条件的数据
  • INNER-JOIN: 多表Join
  • MERGE SORT: 进行merge sort排序,大多是客户端对多线程查询结果进行排序
  • RANGE SCAN: 对主键进行范围扫描,通常有指定start key和stop key
  • ROUND ROBIN: 对查询没有排序要求,并发的在客户端发起扫描请求。
  • SKIP SCAN: Phoenix实现的一种扫描方式,通常能比Range scan获得更好的性能。
  • FULL SCAN: 全表扫描
  • LIMIT: 对查询结果取TOP N
  • CLIENT: 在客户端执行相关操作
  • X-CHUNK: 根据统计信息可以把一个region分成多个CHUNK, X在查询计划中表示将要扫描的CHUNK数量,此处是多线程并发扫描的,并发的数量是由客户端线程池的大小来决定的
  • PARALLEL X-WAY:描述了有X个并发对scan做merge sort之类的客户端操作
  • SERIAL: 单线程串行执行
  • SERVER: 在SERVER端(RS)执行相关操作

2. 查询计划示例说明

分组聚合查询。查询计划中有5385个并发,并行对表做范围扫描,在server端以组合rowkey的第二列k2为过滤条件过滤,并以k2列做聚合。

explain select count(k2) from OFFSET_TEST where k2 = '3343' group by k2;
 
CLIENT 5385-CHUNK 2330168 ROWS 314572800 BYTES PARALLEL 5385-WAY RANGE SCAN OVER OFFSET_TEST [0] - [63]
SERVER FILTER BY FIRST KEY ONLY AND K2 = '3343'
SERVER AGGREGATE INTO DISTINCT ROWS BY [K2]
CLIENT MERGE SORT

无排序查询生成ROUND ROBIN查询计划。查询计划中有5385个并发,并行对表做ROUND ROBIN的范围扫描,在server端以组合rowkey的第二列k2为过滤条件过滤。

explain select * from OFFSET_TEST where k2 = '3343';

CLIENT 5385-CHUNK 2330168 ROWS 314572800 BYTES PARALLEL 5385-WAY ROUND ROBIN RANGE SCAN OVER OFFSET_TEST [0] - [63] 
SERVER FILTER BY K2 = '3343'

有排序查询。查询计划中有5385个并发,并行对表做范围扫描,在server端以组合rowkey的第二列k2为过滤条件过滤并排序,最后在客户端进行merge sort查询结果。

explain select * from OFFSET_TEST where k2 = '3343' order by k2;

CLIENT 5385-CHUNK 2330168 ROWS 314572800 BYTES PARALLEL 5385-WAY RANGE SCAN OVER OFFSET_TEST [0] - [63]
    SERVER FILTER BY K2 = '3343'
    SERVER SORTED BY [K2]
CLIENT MERGE SORT

四、API访问查询计划信息

String explainSql = "EXPLAIN SELECT * FROM T";
Long estimatedBytes = null;
Long estimatedRows = null;
Long estimateInfoTs = null;
try (Statement statement = conn.createStatement(explainSql)) {
        int paramIdx = 1;
        ResultSet rs = statement.executeQuery(explainSql);
        
        //打印查询计划
        System.out.println(QueryUtil.getExplainPlan(rs));
        
        //获取相关估算值
        rs.next();
        estimatedBytes =
                (Long) rs.getObject(PhoenixRuntime.EXPLAIN_PLAN_ESTIMATED_BYTES_READ_COLUMN);
        estimatedRows =
                (Long) rs.getObject(PhoenixRuntime.EXPLAIN_PLAN_ESTIMATED_ROWS_READ_COLUMN);
        estimateInfoTs =
                (Long) rs.getObject(PhoenixRuntime.EXPLAIN_PLAN_ESTIMATE_INFO_TS_COLUMN);
}

五、注意事项

  • 当有两个以上索引表时尽量使用hint去指定查询必须要使用的索引表,这样可以确保即使以后再加了索引不会影响到现在使用的查询计划
  • 能通过数据表组合主键覆盖的查询条件,尽量避免创建索引表。索引表表越多,写放大越严重,维护成本也会随之增加
  • 在查询计划中Scan速度,SKIP SCAN > RANGE SCAN > FULL SCAN
  • 不是所有的查询operations都能下推到server端
  • 查询SERVER FILTER一个普通列,一般会在server端发生全表扫描操作,也需要谨慎检查
  • 组合主键或者组合索引的非前缀列,作为过滤条件列进行查询时,一般会生成SCAN OVER的查询计划,但实际上这种查询也很可能需要全表扫描,所以也需要根据实际情况检查确认

References

目录
相关文章
|
存储 SQL 分布式计算
|
11月前
|
开发框架 监控 .NET
C#进阶-ASP.NET WebForms调用ASMX的WebService接口
通过本文的介绍,希望您能深入理解并掌握ASP.NET WebForms中调用ASMX WebService接口的方法和技巧,并在实际项目中灵活运用这些技术,提高开发效率和应用性能。
705 5
|
存储 Java 应用服务中间件
Java“MissingResourceException”错误解决
Java中的“MissingResourceException”错误通常表示程序在尝试访问资源文件(如属性文件)时未能找到指定的资源。解决此问题的方法包括:确保资源文件存在并位于正确路径,检查文件名和路径是否正确,以及确认类加载器能够访问资源文件。
521 6
|
存储 缓存 运维
有关一次FullGC的故障排查
在收到容器CPU使用率达到104%的告警后,通过日志发现多个线程正在进行批处理任务。初步怀疑Full GC导致CPU占用过高,但内存使用率仅为62%,不符合预期。进一步排查发现监控指标与实际情况不符,最终确认是由于JVM Full GC引起的CPU激增。通过分析堆内存快照,定位到四个大型`List<Map<String, String>>`对象占用了近900MB内存,这些对象由用户上传的Excel转换而来,导致内存膨胀。这些大对象在JVM中长时间驻留,容易触发Full GC。 为解决此问题,提出了两种方案: 1. 将数据存储于缓存而非JVM内存中; 2. 减少内存中对象的数据量,如删除无用字
|
算法 C语言 C++
万字详解:C语言三子棋进阶 + N子棋递归动态判断输赢(一)
三子棋游戏设计的核心是对二维数组的把握和运用。
280 1
|
分布式数据库 Hbase
[Phoenix] 二、数据类型
目前Phoenix支持22种简单数据类型和1个一维Array的复杂类型。
10516 1
|
人工智能 自动驾驶 大数据
官宣!我们和长城汽车在一起了
官宣!我们和长城汽车在一起了
447 0
|
SQL Shell 分布式数据库
[Phoenix] 五、二级索引
目前HBASE只有基于字典序的主键索引,对于非主键过滤条件的查询都会变成扫全表操作,为了解决这个问题Phoenix引入了二级索引功能。然而此二级索引又有别于传统关系型数据库的二级索引,本文将详细描述了Phoenix中二级索引功能、用法和原理。
12851 0
|
存储 SQL 关系型数据库
Phoenix关于时区的处理方式说明
开源版Phoenix对于时区的处理比较混乱,容易造成用户误解、误用。本文梳理了开源Phoenix对于时区的处理逻辑,以及介绍了阿里云Phoenix对时区问题的解决方案。
7075 0
|
存储 分布式数据库 索引
[Phoenix] 十、全局索引设计实践
全局索引是Phoenix的重要特性,合理的使用二级索引能降低查询延时,让集群资源得以充分利用。 本文将讲述如何高效的设计和使用索引。
7116 0