このトピックでは、PolarDB-X 1.0の実行プランの演算子について説明します。これにより、実行プランをクエリしてSQL実行プロセスを表示し、必要に応じてSQLクエリを最適化できます。
実行プラン
PolarDB-X 1.0でSQLクエリを実行すると、オプティマイザはツリー構造として表される実行プランを生成します。 これはほとんどのデータベースシステムに似ています。 リレーショナル演算子で構成されるツリー構造は、PolarDB-X 1.0でSQL文がどのように実行されるかを示します。 他のデータベースシステムとは異なり、PolarDB-X 1.0はデータを格納しませんが、分散環境のネットワークI/Oに重点を置いています。 PolarDB-X V1.0は、ApsaraDB RDS for MySQLやPolarDB for MySQLデータベースなどのデータベースのシャードにコンピューティング操作をプッシュダウンすることで、SQLクエリの実行効率を向上させます。 EXPLAINステートメントを実行して、SQLクエリの実行計画を表示できます。
このトピックのすべての例は、次のスキーマに基づいています。
テーブル 'sbtest1' の作成 (
'id' INT(10) UNSIGNED NOT NULL、
'k' INT(10) 未署名NOT NULLデフォルト '0' 、
'c' CHAR(120) NOT NULL DEFAULT ''、
'pad'CHAR (60) NOT NULL DEFAULT ''、
キー 'xid' ('id') 、
キー 'k_1 ' ('k')
) dbpartition BY HASH ('id') tbpartition BY HASH ('id') tbpartitions 4
次の例は、PolarDB-X 1.0で生成された実行プランのツリー構造を示しています。
、select a.k、count(*) cnt from sbtest1a、sbtest1bについて説明します。a.id = b.kおよびa.id > 1000 group by k hing cnt > 1300 order by cnt limit 5、10;
+ --------------------------------------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ --------------------------------------------------------------------------------------------------------------------------------------------------- +
| TmpSort(sort="cnt ASC" 、offset=?2、fetch=?3) |
| フィルター (condition="cnt > ?1") |
| 集計 (group="k", cnt="COUNT()") |
| BKAJoin(id="id" 、k="k" 、c="c" 、pad="pad" 、id0="id0" 、k0="k0" 、c0="c0" 、pad0="pad0" 、condition="id = k" 、type="inner" |)
| 収集 (sort="k ASC") |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT * FROM 'sbtest1' WHERE ('id' > ?) ORDER BY 'k'") |
| 収集 (同時=true) |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]", shardCount=128, sql="SELECT * FROM 'sbtest1' WHERE (('k' > ?)) AND ('k' IN ('?')))") |
| HitCache:false |
+ --------------------------------------------------------------------------------------------------------------------------------------------------- +
セットの9行 (0.01秒)
EXPLAINステートメントの戻り結果には、実行計画と追加情報の2つの部分が含まれます。
- 実行計画: 演算子間の親子階層は、インデントを使用して表されます。 この例では、FilterはTmpSortの子演算子であり、Aggregateの親演算子です。 SQL文の実行処理では、各演算子は、子演算子の演算結果からデータを取得して処理し、親演算子に出力する。 理解を容易にするために、上記の実行計画はグラフィカルツリー構造に変換されます。
- 追加情報: 実行計画に加えて、EXPLAINステートメントの戻り結果には追加情報も含まれています。
HitCache
のみが追加情報に含まれます。 デフォルトでは、PolarDB-X 1.0は自動的にプランキャッシュ機能を有効にします。HitCache
は、SQLクエリがプランキャッシュにヒットするかどうかを示します。 プランキャッシュ機能を有効にすると、PolarDB-X 1.0はSQL文の定数をプレースホルダ (?
) に置き換えてSQL文をパラメータ化し、パラメータのリストを作成します。 実行計画では、LogicalView演算子のSQLステートメントにプレースホルダー (?
) が含まれています。 一部の演算子には、次のコンテンツが含まれます。? 2
、ここで2
は、パラメータリストでパラメータをマークするために使用される添字を示します。 以下の実施例はさらなる説明を提供する。
EXPLAIN構文
EXPLAINステートメントは、SQLステートメントの実行計画を表示するために使用されます。 次の構文を使用できます。
説明
{LOGICALVIEW | ロジック | シンプル | ディテール | エグゼクティブ | 物理 | オプティマイザー | シェアリング
| コスト | 分析 | ベースライン | JSON_PLAN | アドバイザー}
{SELECT文 | DELETE文 | INSERT文 | REPLACE文 | UPDATE文}
演算子
LogicalViewLogicalView演算子は、基になるデータノードからデータを取得します。 LogicalView演算子は、データベースで一般的に使用されるTableScan
演算子に似ています。 ただし、PolarDB-X 1.0はデータを格納せず、SQL文を使用して基になるデータノードからデータを取得します。 この場合、LogicalView演算子は、pushdown SQLステートメントとデータノードに関する情報を記録するため、ビューと同様に機能します。 ビューには、オプティマイザによってプッシュダウンされるSQLステートメントが含まれており、射影、フィルタリング、集計、並べ替え、結合、サブクエリなどの複数の種類の操作が含まれる場合があります。
次の例は、EXPLAINステートメントのLogicalViewの出力情報と意味を示しています。
selectを説明する * sbtest1からid > 1000;
+ ----------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ ----------------------------------------------------------------------------------------------------------------------- +
| UnionAll(concurrent=true) |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT * FROM 'sbtest1' WHERE ('id' > ?)") |
| HitCache:false |
+ ----------------------------------------------------------------------------------------------------------------------- +
セットの3列 (0.00秒)
LogicalView演算子は、次の3つの部分で構成されます。
- tables: 基になるデータノードに対応するテーブルシャードの名前を指定します。 値はピリオド (.) で分割され
ます。
ピリオドの前の情報 (.) はデータベースシャードのIDを指定し、ピリオドの後の情報 (.) はテーブル名とテーブルシャードIDを指定します。 連続IDは省略される。 たとえば、[000-127]
は、IDが000
から127
の範囲のすべてのテーブルシャードを示します。 - shardCount: アクセスするテーブルシャードの総数。 この例では、IDが
000
から127
の範囲の128テーブルシャードにアクセスします。 - sql: 基になるデータノードにプッシュされるSQL文のテンプレート。 この例に示すSQL文は、実際のpushdown文ではありません。 PolarDB-X 1.0は、SQLの実行中にテーブル名を物理テーブルの名前に置き換えます。 さらに、SQL文の定数
10
は疑問符 (?
) に置き換えられます。 これは、プランキャッシュ機能がデフォルトでPolarDB-X 1.0で有効になっており、SQL文がパラメータ化されているためです。
UnionAllは、SQLのUNION ALL
演算子に対応します。 UnionAll演算子は通常、複数の入力からのデータを組み合わせるために使用されます。 上記の例では、LogicalViewの親演算子として機能するUnionAll演算子は、すべてのテーブルシャードのデータが結合されることを示します。
UnionAll演算子のconcurrent
パラメーターは、サブ演算子を同時に実行するかどうかを指定します。 デフォルト値はtrueです。
UnionAllと同様に、UnionDistinctはSQLのUNION DISTINCT
演算子に対応します。 例:
explain select * From sbtest1 where id > 1000 union different select * From sbtest1 where id < 200;
+ ------------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ ------------------------------------------------------------------------------------------------------------------------- +
| UnionDistinct(concurrent=true) |
| UnionAll(concurrent=true) |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT * FROM 'sbtest1' WHERE ('id' > ?)") |
| UnionAll(concurrent=true) |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT * FROM 'sbtest1' WHERE ('id' < ?)") |
| HitCache:false |
+ ------------------------------------------------------------------------------------------------------------------------- +
セットの6行 (0.02秒)
MergeSortMergeSortは、通常、複数のサブ演算子で動作するマージソート演算子です。 PolarDB-X 1.0は、順序付きデータのマージソートと非順序付きデータのメモリ内ソートの2種類のソートをサポートしています。 例:
select * from sbtest1について説明します。id > 1000 order by id limit 5,10;
+ --------------------------------------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ --------------------------------------------------------------------------------------------------------------------------------------------------- +
| MergeSort(sort="id ASC", offset=?1, fetch=?2) |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]", shardCount=128, sql="SELECT * FROM 'sbtest1' WHERE ('id' > ?) ORDER BY 'id' LIMIT (?? + ?)") |
| HitCache:false |
+ --------------------------------------------------------------------------------------------------------------------------------------------------- +
セットの3列 (0.00秒)
MergeSort演算子は、次の3つの部分で構成されます。
- sort: ソートフィールドとソート順序。
id ASC
は、データがid
フィールドによって昇順にソートされることを示し、DESC
は、データが降順にソートされることを示す。 - offset: 結果セットが取得されたときのオフセット。 この例のSQL文もパラメータ化されています。
オフセット
に設定されます。? 1
、ここで?
は動的パラメータを示し、1はパラメータリストでパラメータをマークするために使用される添字を表します。 この例では、SQLステートメントには1000、5、および10
のパラメーター値が含まれます。 したがって、実際の値は? 1
は5
. - fetch: 返されるデータ行の最大数を指定します。
offset
パラメーターと同様に、このパラメーターの値もパラメーター化されます。 実際の値は10
です。
Aggregate演算子は、データに対して集計操作を実行します。通常、GROUP BY句と集計関数が含まれます。 例:
select k, count(*) from sbtest1 id > 1000 group by k;
+ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| 集計 (group="k", count(*)="SUM(count(*))") |
| MergeSort(sort="k ASC") |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT 'k' 、COUNT(*) AS 'count(*)'FROM 'sbtest1' WHERE ('id' > ?) 'k' ORDER BY 'k'") |
| HitCache:true |
+ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
セットの4列 (0.00秒)
Aggregate演算子は、次の2つの部分で構成されます。
- group: GROUP BY句を示します。 この例では、値は
k
です。 - 集計関数: 集計関数に対応する出力列名は、等号 (
=
) の前に指定します。 集計関数は等号の後に指定されます。 この例のcount(*)="SUM(count(*))"
では、最初のcount(*)
は出力列名に対応し、SUM(count(*))
はcount(*)
列の入力データの合計を返し、count(*)
列に表示される最終結果セットを取得します。
PolarDB − X 1.0は、集約動作を2つのステージに分割する。 最初に、集約操作は、ローカル集約のために基礎となるデータノードにプッシュダウンされます。 次に、PolarDB − X 1.0内のローカルアグリゲーションの結果セットに対してグローバルアグリゲーションが実行される。 さらに、PolarDB-X 1.0でのグローバル集計は、データの並べ替えに基づいて実行されます。 したがって, サードのサブオペレーターが最適化され, 後にMergeSortに変換される.
次のサンプルコードは、AVG
集計関数の例を示しています。
btest1 から, sbtest1 から, sbtest1 から, sbtest1 から1000 g _ id >
+ + +
| ローカルプラン |
+ + +
| プロジェクト (k = "k," avg_id = "sum_pushed_pushed_sum / sum _ pushed_puthed _ count"
アグレート (グループ = "k," sum_pushed_SUM = "SUM (pusked_SUM)," sum_pushed_comunt = "SUM (pusked_comunt)"
| MergeSort(sort="k ASC")|
0000, sql = "SELECT k', SUM ('ID) AS 'pusd _ sum', COUNT ('ID) AS "pusd _ sum," COUNT ('ID) AS 'pusd _ count FROM' 'k'?
| HitCache:false |
+ + +
セット 5 階 (0.01 秒)
PolarDB − X 1.0は、AVG
集計関数をSUMまたはCOUNT
関数に変換する。 次に、SUM
またはCOUNT
関数を使用して、対応するプッシュダウンルールに基づいてローカル集計またはグローバル集計を実行します。 必要に応じて、他の集計関数の実行計画について学ぶことができます。
DISTINCT
演算子をGROUP BY
演算子に変換します。 下のモルコードは例を表す: sbtest1 から, sbtest1 から, sbtest1 から1000.
+ + +
| ローカルプラン |
+ + +
^ a b c / h
| MergeSort(sort="k ASC") |
| LogicalView (table = "0000-0031] .sbtest1 _ [000-127]," shardCount =128, sql = "SELECT 'k' FROM' 'sbtest1 WHERE ('ID >?)
| HitCache:false |
+ + +
セットの4列 (0.02秒)
TMPSORT オペレーターはメモリにデータを調べる. MergeSort演算子は複数のサブ演算子を持つことができ、各サブ演算子によって返されるデータはソートされます。 これは、サブ演算子が1つしかないTmpSort演算子とは異なります。
TmpSort演算子とMergeSort演算子は、実行プランで同じ情報を共有します。 MergeSort演算子の説明を参照してください。
プロジェクトProject演算子は、入力データから列を選択するか、指定した関数または式を使用して指定した列のデータを計算し、結果を返すために使用されます。 Project演算子には定数を含めることもできます。 前述のAVG
集計関数の例では、Project
演算子が一番上にあり、k
とsum_pushed_sum / sum_pushed_count
を返します。 sum_pushed_sum / sum_pushed_countの出力列名はavg_id
です。
"Hello, DRDS" 1 / 2, CURTIME ().
数字 +
| ローカルプラン |
数字 +
| Project (Hello, DRDS = " _UTF-16 'Hello, DRDS," 1 / 2 = "1 / 2" = "1 / 2" CURTIME ().
| |
| HitCache:false |
数字 +
セットの3列 (0.00秒)
Project演算子の実行計画には、指定された各列の名前、SQL文で指定された値、および指定された値の計算に使用される関数または式を含めることができます。
フィルターFilter演算子は、データをフィルタリングするために使用されます。 Filter演算子の実行計画には、データのフィルタリングに使用される条件が含まれます。 この演算子は、入力データをフィルタリングするために使用される。 このオペレーターは, 特定の条件を満たすデータを返す, 特定の条件に満たないデータを返す. 次の例では、前の部分で説明した特定の演算子が使用されます。
、sbtest1からのselect k, avg(id) avg_idについて説明します。id> avg_id > 1300を持つkによる1000グループ。+ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| フィルター (条件="avg_id > ?1") |
| プロジェクト (k="k", avg_id="sum_pushed_sum / sum_pushed_count") |
| 集計 (group="k", sum_pushed_sum="SUM(pushed_sum)", sum_pushed_count="SUM(pushed_count)") |
| MergeSort(sort="k ASC") |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]", shardCount=128, sql="SELECT 'k', SUM('id') AS 'pushed_sum', COUNT('id') AS 'pushed_count' FROM 'sbtest1' WHERE ('id'>) 'k' ORDER 'k' |)
| HitCache:false |
+ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
セットの6行 (0.01秒)
を持つavg_id > 1300
は、AVG
集計関数の前述の例のSQL文に追加されます。 avg_id > 1300
の条件を満たすすべてのデータをフィルタリングするために、Filter演算子が実行計画の最上層に追加されます。
WHERE句にFilter演算子が含まれていない理由が不思議に思うかもしれません。 PolarDB-X 1.0でオプティマイザを実行すると、フィルタ演算子はWHERE句に存在しますが、フィルタ演算子はLogiacalView演算子にプッシュされます。 したがって、id > 1000
条件は、LogicalViewのsql
パラメーターの値に含まれます。
NlJoinは、ネストループを使用して2つのテーブルを結合するネストループ結合演算子に対応します。 PolarDB − X 1.0は、2つのタイプのJOIN演算子、NlJoinおよびBKAJoin (一括鍵アクセス結合) を提供する。 BKAJoinは、左側のテーブルからデータのバッチを読み取り、in条件でデータを使用します。 IN条件は、正しいテーブルにアクセスするためのSQL文に含まれています。 データのバッチは、一度に正しいテーブルから取得されます。
、sbtest1a、sbtest1bからa.* を選択して説明します。a.id = b.kおよびa.id > 1000;
+ ---------------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ ---------------------------------------------------------------------------------------------------------------------------- +
| プロジェクト (id="id" 、k="k" 、c="c" 、pad="pad") |
| NlJoin(id="id" 、k="k" 、c="c" 、pad="pad" 、k0="k0" 、condition="id = k" 、type="inner") |
| UnionAll(concurrent=true) |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT * FROM 'sbtest1' WHERE ('id' > ?)") |
| UnionAll(concurrent=true) |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT 'k' FROM 'sbtest1' WHERE ('k' > ?)") |
| HitCache:false |
+ ---------------------------------------------------------------------------------------------------------------------------- +
セットの7行 (0.03秒)
NlJOIN演算子の実行計画には、次の3つの部分があります。
- 出力列情報: 出力列の名前。 この例では、NlJOIN演算子は、
id="id" 、k="k" 、c="c" 、pad="pad" 、k0="k0"
の5つの出力列を返します。 - condition: 結合条件。 この例では、結合条件として
id = k
が使用されます。 - type: 結合タイプ。 この例では、INNER JOINが使用されます。 したがって、パラメーター値は
inner
です。
BKAJoin演算子は、キーのバッチで結合するテーブルにアクセスすることによってテーブルを結合します。 具体的には、BKAJoinは左側のテーブルからデータのバッチを読み取り、in条件でデータを使用します。 IN条件は、正しいテーブルにアクセスするためのSQL文に含まれています。 結合操作を実行するために、一度に右テーブルからデータのバッチが取得されます。
select a.* from sbtest1a, sbtest1bここでa.id = b.k order by a.id;
+ ------------------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ ------------------------------------------------------------------------------------------------------------------------------- +
| プロジェクト (id="id" 、k="k" 、c="c" 、pad="pad") |
| BKAJoin(id="id" 、k="k" 、c="c" 、pad="pad" 、id0="id0" 、k0="k0" 、c0="c0" 、pad0="pad0" 、condition="id = k" 、type="inner" |)
| MergeSort(sort="id ASC") |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT * FROM 'sbtest1' ORDER BY 'id'") |
| UnionAll(concurrent=true) |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT * FROM 'sbtest1' WHERE ('k' IN ('?'))") |
| HitCache:false |
+ ------------------------------------------------------------------------------------------------------------------------------- +
セットの7行 (0.01秒)
BKAJoin演算子の実行計画は、NlJoin演算子の実行計画と同じです。 これら2つの演算子の違いは、実行者がJOIN操作を実行するために異なるメソッドを使用することです。 上記の実行計画では、右側のテーブルのLogicalViewのコンテンツ 'k' In ('?')
は、右側のテーブルのデータを照会するためにオプティマイザによって構築されるINステートメントテンプレートです。
LogicalView演算子は、データノードからデータを取得するために使用されます。 LogicalModifyView演算子は、データノードのデータを変更するために使用されます。 LogicalModifyViewプランにはSQL文が含まれています。 SQLステートメントには、INSERT、UPDATE、またはDELETEステートメントを使用できます。
、update sbtest1 set c='Hello、DRS 'について説明します。id > 1000;
+ -------------------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ -------------------------------------------------------------------------------------------------------------------------------- +
| LogicalModifyView(tables="[0000-0031].sbtest1_[000-127]", shardCount=128, sql="UPDATE 'sbtest1' SET 'c' = ? WHERE ('id' > ?)") |
| HitCache:false |
+ -------------------------------------------------------------------------------------------------------------------------------- +
セットの2列 (0.03秒)
説明sbtest1からの削除id > 1000;
+ ------------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ ------------------------------------------------------------------------------------------------------------------------- +
| LogicalModifyView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="'sbtest1' WHERE ('id' > ?) から削除する") |
| HitCache:false |
+ ------------------------------------------------------------------------------------------------------------------------- +
セットの2列 (0.03秒)
LogicalModifyViewプランの内容は、LogicalViewプランの内容と似ています。 このプランには、SQL文が実行される物理テーブルシャードの名前、テーブルシャードの数、およびSQLテンプレートが含まれます。 プランキャッシュ機能が有効になっている場合、SQL文はパラメータ化され、SQLテンプレートの定数は疑問符 (?
) に置き換えられます。
PhyTableOperation演算子は、物理テーブルシャードで操作を実行するために使用されます。 この演算子は、INSERT INTO VALUESステートメントで使用できます。
sbtest1値への挿入 (1、1、'1' 、'1') 、(2、2、'2' 、'2') について説明し。+ -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| PhyTableOperation(tables="SYSBENCH_CORONADB_1526954857179TGMMSYSBENCH_CORONADB_VGOC_0000_RDS.[sbtest1_001]", sql="INSERT INTO? ('id' 、'k' 、'c' 、'pad') VALUES(? 、? 、? 、?)"、params=" 'sbtest1_001 '、1,1、1,1 ") |
| PhyTableOperation(tables="SYSBENCH_CORONADB_1526954857179TGMMSYSBENCH_CORONADB_VGOC_0000_RDS.[sbtest1_002]", sql="INSERT INTO? ('id' 、'k' 、'c' 、'pad') VALUES(?, ?, ?, ?)", params=" 'sbtest1_002 ',2,2,2,2 ") |
| |
| HitCache:false |
+ -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
セットの4列 (0.00秒)
この例では、2行のデータが挿入される。 データの各行は、PhyTableOperation演算子に対応します。 PhyTableOperation演算子は、次の3つの部分で構成されます。
- tables: 物理テーブルの名前を指定します。 この例では、PhyTableOperation操作ごとに1つの物理テーブルのみが指定されています。
- sql: SQLテンプレートを指定します。 SQLテンプレートでは、テーブル名と定数はパラメータ化され、疑問符 (
?
) に置き換えられます。 paramsパラメーターは、テーブル名と定数を指定するために使用されます。 - params: テーブル名や定数など、SQLテンプレートに含まれるパラメーターの値を指定します。
その他の情報
HitCacheデフォルトでは、プランキャッシュ機能はPolarDB-X 1.0で有効になっています。 HitCacheは、SQLクエリがプランキャッシュにヒットするかどうかを示します。 次の例では、HitCacheは最初の実行でfalseを返し、2番目の実行でtrueを返します。
selectを説明する * sbtest1からid > 1000;
+ ----------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ ----------------------------------------------------------------------------------------------------------------------- +
| UnionAll(concurrent=true) |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT * FROM 'sbtest1' WHERE ('id' > ?)") |
| HitCache:false |
+ ----------------------------------------------------------------------------------------------------------------------- +
セットの3列 (0.01秒)
explain select * sbtest1からid > 1000;
+ ----------------------------------------------------------------------------------------------------------------------- +
| ローカルプラン |
+ ----------------------------------------------------------------------------------------------------------------------- +
| UnionAll(concurrent=true) |
| LogicalView(tables="[0000-0031].sbtest1_[000-127]" 、shardCount=128、sql="SELECT * FROM 'sbtest1' WHERE ('id' > ?)") |
| HitCache:true |
+ ----------------------------------------------------------------------------------------------------------------------- +
セットの3列 (0.00秒)