tencent cloud

TencentDB for MySQL

動向とお知らせ
製品アップデート情報一覧
初心者ガイド
製品紹介
製品概要
製品の優位性
適用シナリオ
データベースのアーキテクチャ
タグ編集
製品機能リスト
データベースインスタンス
高可用性(マルチアベイラビリティゾーン)
地域とAvailability Zone
自社研究カーネル
TXSQLカーネル概要
機能系特性
パフォーマンス系特性
セキュリティ系特性
安定性系特性
TXRocksエンジン
購入ガイド
課金概要
購入方法
支払い更新の説明
支払い延滞の説明
返金説明
インスタンス調整の料金の説明
バックアップキャパシティ課金説明
クイックスタート
概要
MySQLインスタンスの作成
操作ガイド
使用制限
操作一覧
インスタンスの管理とメンテナンス
アップグレードインスタンス
拡張インスタンス
データベースプロキシ
データベース管理(DMC)
アカウント管理
パラメータ設定
バックアップとロールバック
データ移行
インターネットとセキュリティ
監視とアラーム
ログセンター
タグ
プラクティスチュートリアル
MySQL利用規約
アプリケーションの自動再接続機能のコンフィグレーション
MySQLマスターインスタンスパラメータの変更影響
MyISAMからInnoDBエンジンへの切り替え制限
TencentDB for MySQLのためのVPC作成
MySQLによるサービス負荷能力の向上
2地域3センターのディザスタリカバリ構築
リード・ライト分離によるTencentDB for MySQLパフォーマンスの拡張
DTSでInnoDBデータをRocksDBに移行します
LAMPスタック上のWebアプリケーションの構築
Drupalウエブサイトの構築
Python言語によるMySQL APIの使用
ホワイトペーパー
パフォーマンス白書
セキュリティ白書
トラブルシューティング
接続に関する問題
性能関連
インスタンスデータの同期遅延
大文字と小文字を区別しない設定に失敗しました
APIドキュメント
History
Introduction
API Category
Instance APIs
Making API Requests
Data Import APIs
Database Proxy APIs
Database Audit APIs
Security APIs
Task APIs
Backup APIs
Account APIs
Rollback APIs
Parameter APIs
Database APIs
Monitoring APIs
Log-related API
Data Types
Error Codes
よくある質問
課金関連
ロールバック関連の問題
接続とログインに関する問題
パラメータを変更
アップグレード関連の問題
アカウント権限
性能メモリ
運営する
データ移行
機能特徴
コンソール関連
ログ関連
API 2.0切り替え 3.0ガイド
Service Agreement
Service Level Agreement
Terms of Service
汎用参考
標準と認証
お問い合わせ
用語集
ドキュメントTencentDB for MySQL

Executing SQL and Viewing the Execution Plan

フォーカスモード
フォントサイズ
最終更新日: 2025-05-09 11:51:23
The read-only analysis engine is compatible with the MySQL protocol and syntax. Users can access the read-only analysis engine through the MySQL client or the MySQL connector in the development language to execute SQL statements.
The read-only analysis engine is a read-only instance, so the SQL statements that can be executed are mainly SELECT statements, and the DML and DDL statements cannot be executed. At the same time, queries are strictly subject to object permissions. If the access account does not have the SELECT permission on an object, it cannot view this object either.
When you are executing SQL, you can directly use the MySQL syntax for syntax editing and then execute it in the read-only analysis engine. However, sometimes the execution results may not meet expectations. In this case, you can view the execution plan through the EXPLAIN feature.

EXPLAIN Feature and Usage

Use EXPLAIN to view the execution plan selected when executing query statements in the read-only analysis engine. This is the optimal query plan that is finally selected after multiple stages of optimization by the internal optimizer. When you view the execution plan, SQL will not be executed actually; instead, only the execution plan is output.
The EXPLAIN example is as follows:
EXPLAIN <SELECT_STATMENT>

explain select * from t1 left join t2 on t1.id = t2.id;
The returned result is as follows:
+---------------------------------------------------------------------------------+
| query plan |
+---------------------------------------------------------------------------------+
| ============================================ |
| |ID|OPERATOR |NAME|EST.ROWS| |
| -------------------------------------------- |
| |0 |HASH JOIN | |12500.00| |
| |1 |├─TABLE FULL SCAN (B) |t2 |10000.00| |
| |2 |└─TABLE FULL SCAN (P) |t1 |10000.00| |
| -------------------------------------------- |
| Details: |
| ------------------------------------- |
| 0 - JOIN TYPE: left outer join, EQUAL: [eq(singleton.t1.id, singleton.t2.id)] |
| 1 - STORAGE: LIBRASTORE, BLOCK OFFSET: 1 |
| 2 - STORAGE: LIBRASTORE, BLOCK OFFSET: 1 |
+---------------------------------------------------------------------------------+

Interpretation of EXPLAIN Results

The returned result of EXPLAIN contains the following fields:
ID is the operator number displayed in the plan, which increments downward from 0, facilitating users to view details.
OPERATOR is the operator name, representing the operation performed at each step in the SQL execution.
NAME shows the information such as tables and partitions accessed in the query.
EST.ROWS shows the number of rows that each operator is expected to process, as estimated by the read-only analysis engine based on statistics. If there are no statistics, it will be calculated and displayed based on a default value.

Operator Introduction

An operator is a specific step that is performed to return query results. The following table introduces the names and functions of various operators currently supported by the read-only analysis engine:
Operator Name
Operator Introduction
SORT
The SORT operator is used to sort the input data.
TOPN
If the ORDER BY statement block is followed by a LIMIT statement, the optimizer will further optimize the execution plan, generate a TOP-N SORT operator, and use heapsort to select the TOP-N data.
LIMIT
The LIMIT operator is used to limit the number of rows of data output, which has the same function as the LIMIT operator in MySQL.
FILTER
The FILTER operator is used to perform filtering operations on data according to specified predicate conditions, usually appearing in WHERE/HAVING/ON clauses.
HASH JOIN
Use HASH JOIN to perform JOIN operations on large datasets. The optimizer uses tables in two datasets. The smaller dataset is used to build a HASH table in memory according to the JOIN conditions, and then the database scans the larger dataset and probes the HASH table to find the rows that meet the join conditions.
COLUMN READ
A late materialization operator. The read-only analysis engine supports pushing some filtering conditions down to the TableScan operator. Specifically, it scans the column data related to the filtering conditions first, filters the data to obtain the rows that meet the conditions, and then scans the remaining column data of these rows to continue with subsequent calculations, reducing the computing volume of I/O scans and data processing.
TABLE FULL SCAN
Performs a full-table scan on the target table.
UNION
The UNION operator is used to perform a union operation on the result sets of two queries.
WINDOW FUNCTION
The WINDOW FUNCTION operator is used to implement the analysis functions (also known as window functions) in SQL, calculating the results of relevant rows within the window. Each group of window functions can return multiple rows, and each row within the group is the result of logic calculation based on the window.
HASH GROUP BY
The GROUP BY operator is mainly used for group aggregation calculations in SQL. Ordinary aggregation functions (SUM/MAX/MIN/AVG/COUNT/STDDEV) are completed by allocating the GROUP BY operator.
PROJECTION
A projection operator, corresponding to the SELECT list in SQL statements, has the capability of mapping each input data to new output data.
EXCHANGE RECEIVER
A data receiving operator, used to receive data when various compute nodes exchange data during the MPP query.
EXCHANGE SENDER
A data sending operator, used to send data when various compute nodes exchange data during the MPP query.

Detail Info

In addition to the information shown in the above table of returned results, you can see that a Detail item is displayed below. The Detail item shows some additional information carried by each operator, in the format of n - detail info, where n represents the ID of each operator and what follows is the specific information of each operator. The following table lists the specific information that each operator displays.
Operator Name
Detail Info
SORT
ORDER BY KEY: Represents the sort key used by the sort operator.
TOPN
ORDER BY KEY: Represents the sort key used by the sort operator.
OFFSET: The offset specified by the Limit operation.
COUNT: The number of preserved rows specified by the Limit operation.
LIMIT
OFFSET: The offset specified by the Limit operation.
COUNT: The number of preserved rows specified by the Limit operation.
FILTER
CONDITIONS: Represents the predicate condition adopted by the FILTER operator when filtering data.
HASH JOIN
JOIN TYPE: The current JOIN type, such as inner join, left outer join, and semi join.
NON EQUAL: Specifies whether the current JOIN is a Cartesian product. If this field does not exist, it indicates it is not a Cartesian product.
EQUAL: Displays the equivalent condition adopted when two tables are joined.
OTHER COND: Displays the non-equivalent condition when two tables are joined.
In addition, it can be seen that in the EXPLAIN results above, the operator names with IDs 1 and 2 are followed by the marks (B) and (P) respectively, which mark the Build and Probe sides during the HASH JOIN operation, where B represents Build and P represents Probe.
COLUMN READ
COLUMN READ: The column name read by the late materialization.
TABLE FULL SCAN
STORAGE: The underlying storage type being read. Currently, two types are supported: LIBRASTORE and TDSQL.
BLOCK OFFSET: The query block number of the current table in the entire SQL statement, used to assist with Hint.
UNION
No.
WINDOW FUNCTION
WINDOW FUCN DESCS: The window function name.
PARTITION BY: The partition key.
ORDER BY: The sorting key used for sorting.
FRAME: The window definition of a window function.
HASH GROUP BY
GROUP BY: The group by key specified when executing aggregate functions.
AGG FUNCS: The aggregate functions specified in SQL.
PROJECTION
EXPRS: The list of expressions executed by the PROJECTION operator, mainly including casts being performed and various scalarfuncs.
EXCHANGE RECEIVER
No.
EXCHANGE SENDER
ExchangeType: Methods for data exchange, including:
PASS: Sends data from multiple nodes to one node.
BCJ: Broadcasts data from one node to multiple nodes. For example, broadcast the data from the build table to nodes during JOIN to perform the JOIN operation.
HASH: Distributes data to nodes after it is hashed with the HASH function. For example, scatter and redistribute data from left and right tables during the JOIN operation.
HASH (BY PARTITION): When two tables are involved in a JOIN operation, if one table has a join key that is also its partition key, the other table is shuffled according to the distribution method of the table where the join key is the partition key.
In addition to the basic information of operators in the above table, the two sides of the HASH JOIN operator may have the following two kinds of special detail information when the runtime filter operator is enabled and there is a HASH JOIN operation in the plan.
Probe Runtime Filters: When this information exists on an operator, it means that the current operator applies a runtime filter to filter redundant data.
Build Runtime Filters: This information only appears on the JOIN operator, indicating that a runtime filter has been generated on the build side of the current JOIN operator to filter the redundant data on the probe side in advance. For details on the use and optimization of the runtime filter, and specific effects of the displayed information, see Runtime Filter User Manual.
After EXPLAIN is executed, different operators return different information. You can use Optimizer Hints to control the behavior of the optimizer and thus control the selection of physical operators.
For example, /*+ HASH_JOIN_PROBE(t1) */ indicates that the optimizer forces the use of t1 table as the probe table in the hash join.

ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック