?

Explain Plan
An EXPLAIN plan tells you a lot about how a query will be run:
一個執行計劃會告訴你一個執行計劃怎么執行
All the HBase range queries that will be executed
所有hbase 范圍查詢會被執行
An estimate of the number of bytes that will be scanned
評估多少字節會被掃描
An estimate of the number of rows that will be traversed
評估多少行被遍歷
Time at which the above estimate information was collected
收集上述評估時間
Which HBase table will be used for each scan
每次掃描那個表會使用
Which operations (sort, merge, scan, limit) are executed on the client versus the server
在客戶端和服務端，那個操作 （排序，合并，掃描，限制列數）會被執行
Use an EXPLAIN plan to check how a query will run, and consider rewriting queries to meet the following goals:
用explain plan 執行計劃，檢測一個查詢如何執行，考慮如下目標，來重寫查詢：
Emphasize operations on the server rather than the client. Server operations are distributed across the cluster and operate in parallel, while client operations execute within the single client JDBC driver.
強調在服務器上執行，而不是在客戶端執行。服務器操作是通過分布式集群并發執行，而客戶端是通過單一的jdbc驅動執行。
Use RANGE SCAN or SKIP SCAN whenever possible rather than TABLE SCAN.
使用范圍掃描和跳躍掃描，而不是表級別的掃描。
Filter against leading columns in the primary key constraint. This assumes you have designed the primary key to lead with frequently-accessed or frequently-filtered columns as described in “Primary Keys,” above.
對主導主鍵的列進行過濾。
If necessary, introduce a local index or a global index that covers your query.
如果可以的話，在你的查詢語句中引入本地索引和全局索引覆蓋在你的
If you have an index that covers your query but the optimizer is not detecting it, try hinting the query: SELECT /*+ INDEX() */ …
如果你的查詢語句包含一索引，但是優化器，沒有發現他，你可以試隱示使用select/*+index()*/ 指明
See also: http://phoenix.apache.org/language/index.html#explain

Anatomy of an Explain Plan
剖析 執行計劃
An explain plan consists of lines of text that describe operations that Phoenix will perform during a query, using the following terms:
解釋計劃由Phoenix查詢解釋性執行的操作的文本行組成，使用以下術語:
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操作應用于主鍵約束的主要部分，這允許在適當的位置進行聚合，而不是將所有不同的組保存在服務器端內存中。
AGGREGATE INTO SINGLE ROW—aggregates the results into a single row using an aggregate function with no GROUP BY clause.?
不使用用group by 聚合函數，返回一行的聚合結果集
For example, the count() statement returns one row with the total number of rows that match the query.
例如：count 返回一行匹配查詢條件總記錄數
CLIENT—the operation will be performed on the client side. It’s faster to perform most operations on the server side, so you should consider whether there’s a way to rewrite the query to give the server more of the work to do.
CLIENT -操作將在客戶端執行。在服務端執行會更快，因此你應該考慮重寫使服務做更多的工作。
FILTER BY expression—returns only results that match the expression.
FLETER過濾器 只返回匹配表達式的結果
FULL SCAN OVER tableName—the operation will scan every row in the specified table.
全表掃描，這個操作會掃描指定表的每一行
INNER-JOIN—the operation will join multiple tables on rows where the join condition is met.
內連接-這個操作使用關聯條件，關聯多個表
MERGE SORT—performs a merge sort on the results.
合并排序-對結果集進行合并排序
RANGE SCAN OVER tableName [ … ]—The information in the square brackets indicates the start and stop for each primary key that’s used in the query.
對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.
ROUND ROBIN-當查詢語句沒有 order by 關鍵字，返回的行順序會是隨機的，輪詢調度會再客戶端最大并行的執行
x-CHUNK—describes how many threads will be used for the operation. The maximum parallelism is limited to the number of threads in thread pool.?
x-CHUNK-描述這個操作使用了多少個線程。線程池中最大的并行線程數。
The minimum parallelization corresponds to the number of regions the table has between the start and stop rows of the scan. The number of chunks will increase with a lower guidepost width, as there is more than one chunk per region.
表開始和結束行的之間，最小并行分區數。每一個分區有多個塊，隨著導柱寬度的減小，塊的數量也會增加。
PARALLELx-WAY—describes how many parallel scans will be merge sorted during the operation.
PARALLELx-WAY-在操作期間將合并多少并行掃描會被歸并排序。
SERIAL—some queries run serially. For example, a single row lookup or a query that filters on the leading part of the primary key and limits the results below a configurable threshold.
串行——有些查詢是串行運行的。例如，在主鍵的前導部分進行篩選并將結果限制在可配置閾值以下的單個行查找或查詢。
EST_BYTES_READ - provides an estimate of the total number of bytes that will be scanned as part of executing the query
提供執行查詢的一部分掃描的總字節數的估計值
EST_ROWS_READ - provides an estimate of the total number of rows that will be scanned as part of executing the query
提供執行查詢的一部分掃描的行總數的估計值
EST_INFO_TS - epoch time in milliseconds at which the estimate information was collected
以毫秒為單位的元時間，評估信息收集時間。
Example
+-----------------------------------------------------------------------------------------------------------------------------------
| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PLAN ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | EST_BYTES_READ ?| EST_ROWS_READ ?| EST_INFO_TS ?|
+-----------------------------------------------------------------------------------------------------------------------------------
| CLIENT 36-CHUNK 237878 ROWS 6787437019 BYTES PARALLEL 36-WAY FULL SCAN
| OVER exDocStoreb ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? 237878 ? ? ?| ? 6787437019 ? | 1510353318102|
| ? PARALLEL INNER-JOIN TABLE 0 (SKIP MERGE) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? 237878 ? ? ?| ? 6787437019 ? | 1510353318102|
| ? ? CLIENT 36-CHUNK PARALLEL 36-WAY RANGE SCAN OVER indx_exdocb?
| ? ? ?[0,' 42ecf4abd4bd7e7606025dc8eee3de 6a3cc04418cbc2619ddc01f54d88d7 c3bf']?
| ? ? ?- [0,' 42ecf4abd4bd7e7606025dc8eee3de 6a3cc04418cbc2619ddc01f54d88d7 c3bg' | ? ? 237878 ? ? ?| ? 6787437019 ? | 1510353318102|
| ? ? ? SERVER FILTER BY FIRST KEY ONLY ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? 237878 ? ? ?| ? 6787437019 ? | 1510353318102|
| ? ? ? SERVER AGGREGATE INTO ORDERED DISTINCT ROWS BY ["ID"] ? ? ? ? ? ? ? ? ? ? | ? ? 237878 ? ? ?| ? 6787437019 ? | 1510353318102|
| ? ? CLIENT MERGE SORT ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? 237878 ? ? ?| ? 6787437019 ? | 1510353318102|
| ? DYNAMIC SERVER FILTER BY (A.CURRENT_TIMESTAMP, [A.ID](http://a.id/))?
? ? IN ((TMP.MCT, TMP.TID)) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? 237878 ? ? ?| ? 6787437019 ? | 1510353318102|
+-----------------------------------------------------------------------------------------------------------------------------------
JDBC Explain Plan API and the estimates information
The information displayed in the explain plan API can also be accessed programmatically through the standard JDBC interfaces. When statistics collection is enabled for a table, the explain plan also gives an estimate of number of rows and bytes a query is going to scan. To get hold of the info, you can use corresponding columns in the result set returned by the explain plan statement. When stats collection is not enabled or if for some reason Phoenix cannot provide the estimate information, the columns return null. Below is an example:

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);
? ? ? ? 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);
}

https://phoenix.apache.org/explainplan.html

翻譯不準確的地方，還請大家指正，謝謝

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的phoenix Explain Plan 翻译的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。