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返回的字段

对照两部分表，TIDB的执行计划更偏向于获得集群数据与集群中查询的流转追踪过程，而mysql中更倾向于更纯粹的sql执行过程，如何对sql进行分解。

综上二者的偏向情况还是有所不同。

表1

属性名	含义
id	operator 的 id，在整个执行计划中唯一的标识一个 operator
parents	这个 operator 的 parent。目前的执行计划可以看做是一个 operator 构成的树状结构，数据从 child 流向 parent，每个 operator 的 parent 有且仅有一个
children	这个 operator 的 children，也即是这个 operator 的数据来源
task	当前这个 operator 属于什么 task。目前的执行计划分成为两种 task，一种叫 root task，在 tidb-server 上执行，一种叫 cop task，并行的在 tikv 上执行。当前的执行计划在 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	包含不适合在其他列中显示但十分重要的额外信息