TIDBとMybatis-plusの結合

計画ブロッキングの実行
mybatis-plus実行計画ブロッカーを使用してエラーが発生しました.フィールドExtraが見つかりません.TIDB公式サイトの対応する実行計画の説明ページを検索すると、MysqlとTIDBでexplainが返すフィールドが全く違います.1.TIDB explainが返すフィールド 1 TIDB EXPLAIN:https://pingcap.com/docs-cn/sql/understanding-the-query-execution-plan/ 2. 2 mysql explainが返すフィールド
2つの部分テーブルを比較すると、TIDBの実行計画はクラスタデータとクラスタ内のクエリを取得するフロー追跡プロセスに偏り、mysqlではより純粋なsql実行プロセスに偏り、sqlをどのように分解するかに傾いている.
両者の偏向状況はやはり異なる.
表1
属性名
意味
id
Operatorのidは、実行計画全体で唯一operatorを識別します.
parents
このoperatorのparent.現在の実行計画はoperatorからなるツリー構造と見なすことができ,childからparentにデータが流れ,各operatorのparentが1つしかなく
children
このoperatorのchildren、つまりこのoperatorのデータソース
task
現在このoperatorは何のtaskに属していますか.現在の実行計はroot taskと呼ばれtidb-server上で実行され、cop taskと呼ばれ、tikv上で並列に実行される2つのtaskに分けられている.現在の実行計画のtaskレベルでのトポロジー関係はroot taskの後に多くのcop taskと付き合うことができ、root taskはcop taskの出力結果を入力として使用する.cop taskで実行される、すなわちtidbがtikvにプッシュするタスクであり、各cop taskはtikvクラスタに分散し、複数のプロセスによって共通に実行される
operator info
各operatorの詳細.各operatorのoperator infoはそれぞれ異なりますので、Operator Infoで詳しくご紹介します
count
現在のoperatorが出力する予定のデータバー数は、統計情報およびoperatorの実行論理推定に基づいて
表2
属性名
意味
ID
クエリーでselect句または操作テーブルを実行する順序を示す数値のセットが含まれます.
select_type
クエリー内の各select句のタイプ(単純、複雑)を表します.
table
出力されたローが参照するテーブル
type
MySQLがテーブルに必要なローを見つける方法を表し、「アクセス・タイプ」とも呼ばれます.
possible_keys
MySQLがどのインデックスを使用してテーブルにローを見つけることができるかを示します.クエリーに関連するフィールドにインデックスが存在する場合、そのインデックスはリストされますが、必ずしもクエリーによって使用されるとは限りません.
key
MySQLがクエリで実際に使用したインデックスが表示され、インデックスが使用されていない場合はNULLとして表示されます.クエリーで上書きインデックスが使用されている場合、そのインデックスはkeyリストにのみ表示されます.
key_len
インデックスで使用されるバイト数を表し、クエリで使用されるインデックスの長さを計算します.表示される値は、インデックスフィールドの最大可能な長さです.実際に使用されている長さではありません.key_です.lenは、テーブル定義に基づいて計算され、テーブル内で取得されるものではありません.
row
MySQLは、テーブル統計およびインデックスの選択状況に基づいて、必要なレコードを見つけるために読み込むローの数を推定します.
Extra
他の列に表示するのに適していませんが、非常に重要な追加情報が含まれています.