TiDB 查询优化及调优系列（二）TiDB 查询计划简介

最新推荐文章于 2024-11-09 21:51:58 发布
最新推荐文章于 2024-11-09 21:51:58 发布
阅读量116 收藏 1
点赞数 1
文章标签： tidb 数据库 sql 大数据 性能优化
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42241611/article/details/130411276
版权
本文详细介绍了TiDB查询计划的构成，包括执行算子如TableScan、HashJoin和聚合算子等，以及如何通过EXPLAIN和EXPLAINANALYZE来查看和分析查询的执行过程。文章强调了理解执行顺序和算子的作用对于查询调优的重要性，并提供了多个示例来展示不同类型的Join和聚合操作的执行计划。
摘要由CSDN通过智能技术生成

「TiDB 查询优化及调优」系列文章将通过一些具体的案例，向大家介绍 TiDB 查询及优化相关的原理和应用，在 上一篇文章 中我们简要介绍了 TiDB 查询优化器的优化流程。

查询计划（execution plan）展现了数据库执行 SQL 语句的具体步骤，例如通过索引还是全表扫描访问表中的数据，连接查询的实现方式和连接的顺序等。查阅及理解 TiDB 的查询计划是查询调优的基础。本文为系列文章的第二篇，将着重介绍 TiDB 查询计划以及如何查看。

下载 TiDB 社区版

咨询 TiDB 企业版

免费试用 TiDB Cloud

适用于中国出海企业和开发者

算子及 Task

在上文的 TiDB 查询优化流程简介中有提到过，TiDB 的查询计划是由一系列的执行算子构成，这些算子是为返回查询结果而执行的特定步骤，例如表扫描算子，聚合算子，Join 算子等，下面以表扫描算子为例，其它算子的具体解释可以参看下文查看执行计划的小结。

执行表扫描（读盘或者读 TiKV Block Cache）操作的算子有如下几类：

  • TableFullScan：全表扫描。
  • TableRangeScan：带有范围的表数据扫描。
  • TableRowIDScan：根据上层传递下来的 RowID 扫描表数据。时常在索引读操作后检索符合条件的行。
  • IndexFullScan：另一种“全表扫描”，扫的是索引数据，不是表数据。

目前 TiDB 的计算任务分为两种不同的 task：cop task 和 root task。Cop task 是指使用 TiKV 中的 Coprocessor 执行的计算任务，root task 是指在 TiDB 中执行的计算任务。

SQL 优化的目标之一是将计算尽可能地下推到 TiKV 中执行。TiKV 中的 Coprocessor 能支持大部分 SQL 内建函数（包括聚合函数和标量函数）、SQL LIMIT操作、索引扫描和表扫描。但是，所有的 Join 操作都只能作为 root task 在 TiDB 上执行。

利用 EXPLAIN 查看分析查询计划

与其它主流商业数据库一样，TiDB 中可以通过 EXPLAIN 语句返回的结果查看某条 SQL 的执行计划。

EXPLAIN 语句

目前 TiDB 的 EXPLAIN 主要输出 5 列，分别是：id，estRows，task，access object， operator info。执行计划中每个算子都由这 5 列属性来描述，EXPLAIN结果中每一行描述一个算子。每个属性的具体含义如下：

EXPLAIN ANALYZE 语句

和 EXPLAIN不同，EXPLAIN ANALYZE会执行对应的 SQL 语句，记录其运行时信息，和执行计划一并返回出来，可以视为 EXPLAIN语句的扩展。EXPLAIN ANALYZE语句的返回结果中增加了 actRows, execution info, memory, disk这几列信息：

例如在下例中，优化器估算的 estRows和实际执行中统计得到的 actRows几乎是相等的，说明优化器估算的行数与实际行数的误差很小。同时IndexLookUp_10算子在实际执行过程中使用了约 9 KB 的内存，该 SQL 在执行过程中，没有触发过任何算子的落盘操作。

mysql> explain analyze select * from t where a < 10;
+-------------------------------+---------+---------+-----------+-------------------------+------------------------------------------------------------------------+-----------------------------------------------------+---------------+------+
| id                            | estRows | actRows | task      | access object           | execution info                                                         | operator info                                       | memory        | disk |
+-------------------------------+---------+---------+-----------+-------------------------+------------------------------------------------------------------------+-----------------------------------------------------+---------------+------+
| IndexLookUp_10                | 9.00    | 9       | root      |                         | time:641.245µs, loops:2, rpc num: 1, rpc time:242.648µs, proc keys:0   |                                                     | 9.23046875 KB | N/A  |
| ├─IndexRangeScan_8(Build)     | 9.00    | 9       | cop[tikv] | table:t, index:idx_a(a) | time:142.94µs, loops:10,                                               | range:[-inf,10), keep order:false                   | N/A           | N/A  |
| └─TableRowIDScan_9(Probe)     | 9.00    | 9       | cop[tikv] | table:t                 | time:141.128µs, loops:10                                               | keep order:false                                    | N/A           | N/A  |
+-------------------------------+---------+---------+-----------+-------------------------+------------------------------------------------------------------------+-----------------------------------------------------+---------------+------+
3 rows in set (0.00 sec)

查看计划中算子的执行顺序

TiDB 的执行计划是一个树形结构，树中每个节点即是算子。考虑到每个算子内多线程并发执行的情况，在一条 SQL 执行的过程中，如果能够有一个手术刀把这棵树切开看看，大家可能会发现所有的算子都正在消耗 CPU 和内存处理数据，从这个角度来看，算子是没有执行顺序的。

但是如果从一行数据先后被哪些算子处理的角度来看，一条数据在算子上的执行是有顺序的。这个顺序可以通过下面这个规则简单总结出来：

Build总是先于 Probe执行，并且 Build总是出现 Probe前面

这个原则的前半句是说：如果一个算子有多个子节点，子节点 ID 后面有 Build关键字的算子总是先于有 Probe关键字的算子执行。后半句是说：TiDB 在展现执行计划的时候，Build端总是第一个出现，接着才是 Probe端。例如：

TiDB(root@127.0.0.1:test) > explain select * from t use index(idx_a) where a = 1;
+-------------------------------+---------+-----------+-------------------------+---------------------------------------------+
| id                            | estRows | task      | access object           | operator info                               |
+-------------------------------+---------+-----------+-------------------------+---------------------------------------------+
| IndexLookUp_7                 | 10.00   | root      |                         |                                             |
| ├─IndexRangeScan_5(Build)     | 10.00   | cop[tikv] | table:t, index:idx_a(a) | range:[1,1], keep order:false, stats:pseudo |
| └─TableRowIDScan_6(Probe)     | 10.00   | cop[tikv] | table:t                 | keep order:false, stats:pseudo              |
+-------------------------------+---------+-----------+-------------------------+---------------------------------------------+
3 rows in set (0.00 sec)

这里 IndexLookUp_7算子有两个孩子节点：IndexRangeScan_5(Build)和 TableRowIDScan_6(Probe)。可以看到，IndexRangeScan_5(Build)是第一个出现的，并且基于上面这条规则，要得到一条数据，需要先执行它得到一个 RowID以后，再由 TableRowIDScan_6(Probe)根据前者读上来的 RowID去获取完整的一行数据。

这种规则隐含的另一个信息是：在同一层级的节点中，出现在最前面的算子可能是最先被执行的，而出现在最末尾的算子可能是最后被执行的。

例如下面这个例子：

TiDB(root@127.0.0.1:test) > explain select * from t t1 use index(idx_a) join t t2 use index() where t1.a = t2.a;
+----------------------------------+----------+-----------+--------------------------+------------------------------------------------------------------+
| id                               | estRows  | task      | access object            | operator info                                                    |
+----------------------------------+----------+-----------+--------------------------+------------------------------------------------------------------+
| HashJoin_22                      | 12487.50 | root      |                          | inner join, inner:TableReader_26, equal:[eq(test.t.a, test.t.a)] |
| ├─TableReader_26(Build)          | 9990.00  | root      |                          | data:Selection_25                                                |
| │ └─Selection_25                 | 9990.00  | cop[tikv] |                          | not(isnull(test.t.a))                                            |
| │   └─TableFullScan_24           | 10000.00 | cop[tikv] | table:t2                 | keep order:false, stats:pseudo                                   |
| └─IndexLookUp_29(Probe)          | 9990.00  | root      |                          |                                                                  |
|   ├─IndexFullScan_27(Build)      | 9990.00  | cop[tikv] | table:t1, index:idx_a(a) | keep order:false, stats:pseudo                                   |
|   └─TableRowIDScan_28(Probe)     | 9990.00  | cop[tikv] | table:t1                 | keep order:false, stats:pseudo                                   |
+----------------------------------+----------+-----------+--------------------------+------------------------------------------------------------------+
7 rows in set (0.00 sec)

要完成 HashJoin_22，需要先执行 TableReader_26(Build)再执行 IndexLookUp_29(Probe)。而在执行 IndexLookUp_29(Probe)的时候，又需要先执行 IndexFullScan_27(Build)再执行 TableRowIDScan_28(Probe)。所以从整条执行链路来看，TableRowIDScan_28(Probe)是最后被唤起执行的。

查看表扫描的执行计划

在上文介绍算子和任务时已经提到过表扫描算子，这里再稍微重复介绍一下，分为执行表扫描操作的算子和对扫描数据进行汇聚和计算的算子：

执行表扫描（读盘或者读 TiKV Block Cache）操作的算子有如下几类：

  • TableFullScan：全表扫描。
  • TableRangeScan：带有范围的表数据扫描。
  • TableRowIDScan：根据上层传递下来的 RowID 扫描表数据。时常在索引读操作后检索符合条件的行。
  • IndexFullScan：另一种“全表扫描”，扫的是索引数据，不是表数据。
  • IndexRangeScan：带有范围的索引数据扫描操作。

TiDB 会汇聚 TiKV/TiFlash 上扫描的数据或者计算结果，这种“数据汇聚”算子目前有如下几类：

  • TableReader：将 TiKV 上底层扫表算子 TableFullScan 或 TableRangeScan 得到的数据进行汇总。
  • IndexReader：将 TiKV 上底层扫表算子 IndexFullScan 或 IndexRangeScan 得到的数据进行汇总。
  • IndexLookUp：先汇总 Build 端 TiKV 扫描上来的 RowID，再去 Probe 端上根据这些 RowID精确地读取 TiKV 上的数据。Build 端是 IndexFullScan或 IndexRangeScan类型的算子，Probe 端是 TableRowIDScan类型的算子。
  • IndexMerge：和 IndexLookupReader类似，可以看做是它的扩展，可以同时读取多个索引的数据，有多个 Build 端，一个 Probe 端。执行过程也很类似，先汇总所有 Build 端 TiKV 扫描上来的 RowID，再去 Probe 端上根据这些 RowID 精确地读取 TiKV 上的数据。Build 端是 IndexFullScan或 IndexRangeScan类型的算子，Probe 端是 TableRowIDScan类型的算子。

IndexLookUp 示例：

mysql> explain select * from t use index(idx_a);
+-------------------------------+----------+-----------+-------------------------+--------------------------------+
| id                            | estRows  | task      | access object           | operator info                  |
+-------------------------------+----------+-----------+-------------------------+--------------------------------+
| IndexLookUp_6                 | 10000.00 | root      |                         |                                |
| ├─IndexFullScan_4(Build)      | 10000.00 | cop[tikv] | table:t, index:idx_a(a) | keep order:false, stats:pseudo |
| └─TableRowIDScan_5(Probe)     | 10000.00 | cop[tikv] | table:t                 | keep order:false, stats:pseudo |
+-------------------------------+----------+-----------+-------------------------+--------------------------------+
3 rows in set (0.00 sec)

这里 IndexLookUp_6算子有两个孩子节点：IndexFullScan_4(Build)和 TableRowIDScan_5(Probe)。可以看到，IndexFullScan_4(Build)执行索引全表扫，扫描索引 a的所有数据，因为是全范围扫，这个操作将获得表中所有数据的 RowID，之后再由 TableRowIDScan_5(Probe)去根据这些 RowID去扫描所有的表数据。可以预见的是，这个执行计划不如直接使用 TableReader 进行全表扫，因为同样都是全表扫，这里的 IndexLookUp多扫了一次索引，带来了额外的开销。

TableReader 示例：

mysql> explain select * from t where a > 1 or b >100;
+-------------------------+----------+-----------+---------------+----------------------------------------+
| id                      | estRows  | task      | access object | operator info                          |
+-------------------------+----------+-----------+---------------+----------------------------------------+
| TableReader_7           | 8000.00  | root      |               | data:Selection_6                       |
| └─Selection_6           | 8000.00  | cop[tikv] |               | or(gt(test.t.a, 1), gt(test.t.b, 100)) |
|   └─TableFullScan_5     | 10000.00 | cop[tikv] | table:t       | keep order:false, stats:pseudo         |
+-------------------------+----------+-----------+---------------+----------------------------------------+
3 rows in set (0.00 sec)

在上面例子中 TableReader_7算子的孩子节点是 Selection_6。以这个孩子节点为根的子树被当做了一个 Cop Task下发给了相应的 TiKV，这个 Cop Task使用 TableFullScan_5算子执行扫表操作。Selection 表示 SQL 语句中的选择条件，可能来自 SQL 语句中的 WHERE/HAVING/ON子句。由 TableFullScan_5可以看到，这个执行计划使用了一个全表扫描的操作，集群的负载将因此而上升，可能会影响到集群中正在运行的其他查询。这时候如果能够建立合适的索引，并且使用 IndexMerge算子，将能够极大的提升查询的性能，降低集群的负载。

IndexMerge 示例：

注意：目前 TIDB 的 Index Merge为实验特性在 5.3 及以前版本中默认关闭，同时 5.0 中的 Index Merge目前支持的场景仅限于析取范式（or 连接的表达式），对合取范式（and 连接的表达式）将在之后的版本中支持。 开启 Index Merge特性，可通过在客户端中设置 session 或者 global 变量完成：set @@tidb_enable_index_merge = 1;

mysql> set @@tidb_enable_index_merge = 1;
mysql> explain select * from t use index(idx_a, idx_b) where a > 1 or b > 1;
+------------------------------+---------+-----------+-------------------------+------------------------------------------------+
| id                           | estRows | task      | access object           | operator info                                  |
+------------------------------+---------+-----------+-------------------------+------------------------------------------------+
| IndexMerge_16                | 6666.67 | root      |                         |                                                |
| ├─IndexRangeScan_13(Build)   | 3333.33 | cop[tikv] | table:t, index:idx_a(a) | range:(1,+inf], keep order:false, stats:pseudo |
| ├─IndexRangeScan_14(Build)   | 3333.33 | cop[tikv] | table:t, index:idx_b(b) | range:(1,+inf], keep order:false, stats:pseudo |
| └─TableRowIDScan_15(Probe)   | 6666.67 | cop[tikv] | table:t                 | keep order:false, stats:pseudo                 |
+------------------------------+---------+-----------+-------------------------+------------------------------------------------+
4 rows in set (0.00 sec)

IndexMerge使得数据库在扫描表数据时可以使用多个索引。这里 IndexMerge_16算子有三个孩子节点，其中 IndexRangeScan_13和 IndexRangeScan_14根据范围扫描得到符合条件的所有 RowID，再由 TableRowIDScan_15算子根据这些 RowID精确的读取所有满足条件的数据。

查看聚合计算的执行计划

Hash Aggregate 示例：

TiDB 上的 Hash Aggregation 算子采用多线程并发优化，执行速度快，但会消耗较多内存。下面是一个 Hash Aggregate 的例子：

TiDB(root@127.0.0.1:test) > explain select /*+ HASH_AGG() */ count(*) from t;
+---------------------------+----------+-----------+---------------+---------------------------------+
| id                        | estRows  | task      | access object | operator info                   |
+---------------------------+----------+-----------+---------------+---------------------------------+
| HashAgg_11                | 1.00     | root      |               | funcs:count(Column#7)->Column#4 |
| └─TableReader_12          | 1.00     | root      |               | data:HashAgg_5                  |
|   └─HashAgg_5             | 1.00     | cop[tikv] |               | funcs:count(1)->Column#7        |
|     └─TableFullScan_8     | 10000.00 | cop[tikv] | table:t       | keep order:false, stats:pseudo  |
+---------------------------+----------+-----------+---------------+---------------------------------+
4 rows in set (0.00 sec)

一般而言 TiDB 的 Hash Aggregate会分成两个阶段执行，一个在 TiKV/TiFlash 的 Coprocessor上，计算聚合函数的中间结果。另一个在 TiDB 层，汇总所有 Coprocessor Task的中间结果后，得到最终结果。

Stream Aggregate 示例：

TiDB Stream Aggregation算子通常会比 Hash Aggregate占用更少的内存，有些场景中也会比 Hash Aggregate执行的更快。当数据量太大或者系统内存不足时，可以试试 Stream Aggregate算子。一个 Stream Aggregate的例子如下：

TiDB(root@127.0.0.1:test) > explain select /*+ STREAM_AGG() */ count(*) from t;
+----------------------------+----------+-----------+---------------+---------------------------------+
| id                         | estRows  | task      | access object | operator info                   |
+----------------------------+----------+-----------+---------------+---------------------------------+
| StreamAgg_16               | 1.00     | root      |               | funcs:count(Column#7)->Column#4 |
| └─TableReader_17           | 1.00     | root      |               | data:StreamAgg_8                |
|   └─StreamAgg_8            | 1.00     | cop[tikv] |               | funcs:count(1)->Column#7        |
|     └─TableFullScan_13     | 10000.00 | cop[tikv] | table:t       | keep order:false, stats:pseudo  |
+----------------------------+----------+-----------+---------------+---------------------------------+
4 rows in set (0.00 sec)

和 Hash Aggregate类似，一般而言 TiDB 的 Stream Aggregate也会分成两个阶段执行，一个在 TiKV/TiFlash 的 Coprocessor上，计算聚合函数的中间结果。另一个在 TiDB 层，汇总所有 Coprocessor Task的中间结果后，得到最终结果。

查看 Join 的执行计划

TiDB 的 Join 算法包括如下几类：

  • Hash Join
  • Merge Join
  • Index Hash Join
  • Index Merge Join

Apply

下面分别通过一些例子来解释这些 Join 算法的执行过程

Hash Join 示例：

TiDB 的 Hash Join 算子采用了多线程优化，执行速度较快，但会消耗较多内存。一个 Hash Join 的例子如下：

mysql> explain select /*+ HASH_JOIN(t1, t2) */ * from t t1 join t2 on t1.a = t2.a;
+------------------------------+----------+-----------+---------------+-------------------------------------------------------------------+
| id                           | estRows  | task      | access object | operator info                                                     |
+------------------------------+----------+-----------+---------------+-------------------------------------------------------------------+
| HashJoin_33                  | 10000.00 | root      |               | inner join, inner:TableReader_43, equal:[eq(test.t.a, test.t2.a)] |
| ├─TableReader_43(Build)      | 10000.00 | root      |               | data:Selection_42                                                 |
| │ └─Selection_42             | 10000.00 | cop[tikv] |               | not(isnull(test.t2.a))                                            |
| │   └─TableFullScan_41       | 10000.00 | cop[tikv] | table:t2      | keep order:false                                                  |
| └─TableReader_37(Probe)      | 10000.00 | root      |               | data:Selection_36                                                 |
|   └─Selection_36             | 10000.00 | cop[tikv] |               | not(isnull(test.t.a))                                             |
|     └─TableFullScan_35       | 10000.00 | cop[tikv] | table:t1      | keep order:false                                                  |
+------------------------------+----------+-----------+---------------+-------------------------------------------------------------------+
7 rows in set (0.00 sec)

Hash Join会将 Build端的数据缓存在内存中，根据这些数据构造出一个 Hash Table，然后读取 Probe端的数据，用 Probe端的数据去探测（Probe）Build端构造出来的 Hash Table，将符合条件的数据返回给用户。

Merge Join示例： TiDB 的 Merge Join算子相比于 Hash Join通常会占用更少的内存，但可能执行时间会更久。当数据量太大，或系统内存不足时，建议尝试使用。下面是一个 Merge Join的例子：

mysql> explain select /*+ SM_JOIN(t1) */ * from t t1 join t t2 on t1.a = t2.a;
+------------------------------------+----------+-----------+--------------------------+---------------------------------------------------+
| id                                 | estRows  | task      | access object            | operator info                                     |
+------------------------------------+----------+-----------+--------------------------+---------------------------------------------------+
| MergeJoin_6                        | 10000.00 | root      |                          | inner join, left key:test.t.a, right key:test.t.a |
| ├─IndexLookUp_13(Build)            | 10000.00 | root      |                          |                                                   |
| │ ├─IndexFullScan_11(Build)        | 10000.00 | cop[tikv] | table:t2, index:idx_a(a) | keep order:true                                   |
| │ └─TableRowIDScan_12(Probe)       | 10000.00 | cop[tikv] | table:t2                 | keep order:false                                  |
| └─IndexLookUp_10(Probe)            | 10000.00 | root      |                          |                                                   |
|   ├─IndexFullScan_8(Build)         | 10000.00 | cop[tikv] | table:t1, index:idx_a(a) | keep order:true                                   |
|   └─TableRowIDScan_9(Probe)        | 10000.00 | cop[tikv] | table:t1                 | keep order:false                                  |
+------------------------------------+----------+-----------+--------------------------+---------------------------------------------------+
7 rows in set (0.00 sec)

Merge Join算子在执行时，会从 Build端把一个 Join Group的数据全部读取到内存中，接着再去读 Probe端的数据，用 Probe端的每行数据去和 Build端的完整的一个 Join Group依次去看是否匹配（除了满足等值条件以外，还有其他非等值条件，这里的 “匹配” 主要是指查看是否满足非等值职条件）。Join Group指的是所有 Join Key上值相同的数据。

Index Hash Join 示例：

INL_HASH_JOIN(t1_name [, tl_name])提示优化器使用 Index Nested Loop Hash Join算法。该算法与 Index Nested Loop Join使用条件完全一样，但在某些场景下会更为节省内存资源。

mysql> explain select /*+ INL_HASH_JOIN(t1) */ * from t t1 join t t2 on t1.a = t2.a;
+----------------------------------+----------+-----------+--------------------------+--------------------------------------------------------------------------+
| id                               | estRows  | task      | access object            | operator info                                                            |
+----------------------------------+----------+-----------+--------------------------+--------------------------------------------------------------------------+
| IndexHashJoin_32                 | 10000.00 | root      |                          | inner join, inner:IndexLookUp_23, outer key:test.t.a, inner key:test.t.a |
| ├─TableReader_35(Build)          | 10000.00 | root      |                          | data:Selection_34                                                        |
| │ └─Selection_34                 | 10000.00 | cop[tikv] |                          | not(isnull(test.t.a))                                                    |
| │   └─TableFullScan_33           | 10000.00 | cop[tikv] | table:t2                 | keep order:false                                                         |
| └─IndexLookUp_23(Probe)          | 1.00     | root      |                          |                                                                          |
|   ├─Selection_22(Build)          | 1.00     | cop[tikv] |                          | not(isnull(test.t.a))                                                    |
|   │ └─IndexRangeScan_20          | 1.00     | cop[tikv] | table:t1, index:idx_a(a) | range: decided by [eq(test.t.a, test.t.a)], keep order:false             |
|   └─TableRowIDScan_21(Probe)     | 1.00     | cop[tikv] | table:t1                 | keep order:false                                                         |
+----------------------------------+----------+-----------+--------------------------+--------------------------------------------------------------------------+
8 rows in set (0.00 sec)

Index Merge Join 示例： INL_MERGE_JOIN(t1_name [, tl_name])提示优化器使用 Index Nested Loop Merge Join算法。该算法相比于 INL_JOIN会更节省内存。该算法使用条件包含 INL_JOIN的所有使用条件，但还需要添加一条：join keys中的内表列集合是内表使用的 index的前缀，或内表使用的 index是 join keys中的内表列集合的前缀。

mysql> explain select /*+ INL_MERGE_JOIN(t2@sel_2) */ * from t t1 where  t1.a  in ( select t2.a from t t2 where t2.b < t1.b);
+---------------------------------+---------+-----------+--------------------------+-----------------------------------------------------------------------------------------------------------+
| id                              | estRows | task      | access object            | operator info                                                                                             |
+---------------------------------+---------+-----------+--------------------------+-----------------------------------------------------------------------------------------------------------+
| IndexMergeJoin_23               | 6.39    | root      |                          | semi join, inner:Projection_21, outer key:test.t.a, inner key:test.t.a, other cond:lt(test.t.b, test.t.b) |
| ├─TableReader_28(Build)         | 7.98    | root      |                          | data:Selection_27                                                                                         |
| │ └─Selection_27                | 7.98    | cop[tikv] |                          | not(isnull(test.t.a)), not(isnull(test.t.b))                                                              |
| │   └─TableFullScan_26          | 8.00    | cop[tikv] | table:t1                 | keep order:false, stats:pseudo                                                                            |
| └─Projection_21(Probe)          | 1.25    | root      |                          | test.t.a, test.t.b                                                                                        |
|   └─IndexLookUp_20              | 1.25    | root      |                          |                                                                                                           |
|     ├─Selection_18(Build)       | 1.25    | cop[tikv] |                          | not(isnull(test.t.a))                                                                                     |
|     │ └─IndexRangeScan_16       | 1.25    | cop[tikv] | table:t2, index:idx_a(a) | range: decided by [eq(test.t.a, test.t.a)], keep order:true, stats:pseudo                                 |
|     └─Selection_19(Probe)       | 1.25    | cop[tikv] |                          | not(isnull(test.t.b))                                                                                     |
|       └─TableRowIDScan_17       | 1.25    | cop[tikv] | table:t2                 | keep order:false, stats:pseudo                                                                            |
+---------------------------------+---------+-----------+--------------------------+-----------------------------------------------------------------------------------------------------------+
10 rows in set (0.01 sec)
```sql

Apply 示例：

```sql
mysql> explain select * from t t1 where  t1.a  in ( select avg(t2.a) from t2 where t2.b < t1.b);
+----------------------------------+----------+-----------+---------------+-------------------------------------------------------------------------------+
| id                               | estRows  | task      | access object | operator info                                                                 |
+----------------------------------+----------+-----------+---------------+-------------------------------------------------------------------------------+
| Projection_10                    | 10000.00 | root      |               | test.t.id, test.t.a, test.t.b                                                 |
| └─Apply_12                       | 10000.00 | root      |               | semi join, inner:StreamAgg_30, equal:[eq(Column#8, Column#7)]                 |
|   ├─Projection_13(Build)         | 10000.00 | root      |               | test.t.id, test.t.a, test.t.b, cast(test.t.a, decimal(20,0) BINARY)->Column#8 |
|   │ └─TableReader_15             | 10000.00 | root      |               | data:TableFullScan_14                                                         |
|   │   └─TableFullScan_14         | 10000.00 | cop[tikv] | table:t1      | keep order:false                                                              |
|   └─StreamAgg_30(Probe)          | 1.00     | root      |               | funcs:avg(Column#12, Column#13)->Column#7                                     |
|     └─TableReader_31             | 1.00     | root      |               | data:StreamAgg_19                                                             |
|       └─StreamAgg_19             | 1.00     | cop[tikv] |               | funcs:count(test.t2.a)->Column#12, funcs:sum(test.t2.a)->Column#13            |
|         └─Selection_29           | 8000.00  | cop[tikv] |               | lt(test.t2.b, test.t.b)                                                       |
|           └─TableFullScan_28     | 10000.00 | cop[tikv] | table:t2      | keep order:false                                                              |
+----------------------------------+----------+-----------+-----------------------------------------------------------------------------------------------+
10 rows in set, 1 warning (0.00 sec)

其它关于 EXPLAIN 的说明

EXPLAIN FOR CONNECTION用于获得一个连接中最后执行的查询的执行计划，其输出格式与 EXPLAIN完全一致。但 TiDB 中的实现与 MySQL 不同，除了输出格式之外，还有以下区别：

MySQL 返回的是正在执行的查询计划，而 TiDB 返回的是最后执行的查询计划。

MySQL 的文档中指出，MySQL 要求登录用户与被查询的连接相同，或者拥有 PROCESS权限，而 TiDB 则要求登录用户与被查询的连接相同，或者拥有 SUPER权限。

每天读点书学堂
关注
TiDB执行计划概述
star_apple的博客
09-25 719
在TiDB中可以使用explain和explain analyze来查看sql的执行计划。两者区别：explain不会区执行sql，而explain analyze会去执行sql，另外explain analyze显示的内容比explain更全面。
TiDB 查询优化及调优系列：深入了解 TiDB 查询计划
FdhApps的博客
09-18 237
通过合理地收集统计信息、使用索引、优化查询语句和调整配置项，我们可以优化查询计划，提高查询性能，从而更好地利用 TiDB 的强大功能。d. 查询优化：TiDB 使用成本模型和规则匹配等技术，生成多个候选的查询计划，并评估其执行代价，选择代价最小的计划作为最终的查询计划。通过适当地收集统计信息、使用索引、优化查询语句以及调整配置项，可以提高 TiDB 的查询性能和效率，获得更好的查询计划。c. 查询重写：TiDB 对查询语句进行重写，根据查询的特性和统计信息，对查询条件、连接顺序等进行优化。
TiDB学习笔记（六）-数据库查询优化
干货满满~
04-17 1915
预处理阶段 针对点查进行优化（直接下推到SQL执行器。优化原因：优化方式单一，使用频率最高。） 构造出事的逻辑执行计划 常量折叠 表达式简化 子查询处理（子查询转换为表连接） 逻辑优化 列剪裁 分区剪裁 聚合消除 MAX/MIN优化 投影消除 外连接消除 谓词下推 连接顺序调整 物理优化 扫描方式 全表扫描 索引扫描-索引选择 算子物理实现方式 聚合算子 连接算子 排序算子 是否将算子下推到存储层 聚合算子 limit算子 Top..
TiDB 查询优化及调优系列（一）TiDB 优化器简介
TiDB_PingCAP 的博客
04-14 965
「TiDB 查询优化及调优」系列文章将通过一些具体的案例，向大家介绍 TiDB 查询及优化相关的原理和应用。本文为系列文章的第一篇，将简要介绍 TiDB 的查询优化器的优化流程。
TiDB 性能分析&性能调优&优化实践大全
TiDB 社区干货传送门
06-20 2030
本文介绍了基于数据库时间的系统优化方法，以及如何利用 TiDB Performance Overview 面板 8进行性能分析和优化。通过本文中介绍的方法，你可以从全局、自顶向下的角度分析用户响应时间和数据库时间，确认用户响应时间的瓶颈是否在数据库中。如果瓶颈在数据库中，你可以通过数据库时间概览和 SQL 延迟的分解，定位数据库内部的瓶颈点，并进行针对性的优化。TiDB 对 SQL 的处理路径和数据库时间进行了完善的测量和记录，方便定位数...
TiDB 查询优化及调优系列案例实践
FdhApps的博客
09-18 105
在实际应用中，为了提高查询性能和系统的整体效率，需要对 TiDB 进行查询优化和调优。本文将通过一系列实际案例，介绍一些常见的查询优化和调优技巧，并提供相应的源代码。本文通过索引优化和连接优化两个案例，介绍了一些常用的查询优化技巧。通过合理地创建索引和优化连接操作，可以显著提高查询性能和系统的整体效率。在 TiDB 中，可以通过创建合适的索引来加速查询。在复杂的查询中，经常涉及多个表之间的连接操作。以上是 TiDB 查询优化及调优的实践案例，希望对你有所帮助。的联合索引，我们可以提高连接操作的效率。
TiDB分布式写入性能调优实战与架构解析
在分布式系统环境下，如NewSQL数据库TiDB的性能调优是一项关键...对TiDB进行性能调优是一个系统性的过程，需要全面考虑各个组件和环节的交互，不断收集数据、诊断问题，并通过适当的参数调整和优化策略来提升整体性能。
TiDB监控与优化：参数调优与指标解读
本资源是一份详尽的IT技术文档，主要关注于监控指标解读和TiDB数据库的优化，特别是针对2020年的McM问题A。文档首先介绍了TiDB，一种分布式NewSQL数据库，特别强调了其参数管理和热点分散策略。 在数据库优化部分，...
如何对分布式 NewSQL 数据库 TiDB 进行性能调优1
08-03
在分布式 NewSQL 数据库 TiDB 的性能调优中，我们需要关注多个层面的优化，以确保系统的高效运行。TiDB 是一个分布式 HTAP 数据库，由 TiDB 服务、TiKV 存储服务和 PD 管理组件构成，提供无状态 SQL 接口和强一致性...
TiDB学习笔记（七）-数据库系统优化
干货满满~
04-20 2059
一、TiDB Server 关键性能参数与优化 处理器-动态节能技术 cpupower frequency-set --governor performance 处理器-中断亲和性 NUMA绑核 内存-透明大页 内存-虚拟内存参数 存储及文件系统 I/O调度器 格式化参数-块大小 挂载参数 网络 二、PD 关键性能参数与优化 三、TiKV 关键性能参数与优化 线程池调优 gPRC线程池 负责网络IO，反序列化， server.grpc-concurrency 默..
TIDB SQL优化进阶(join方式的选择)
weixin_40981792的博客
08-07 3734
1.理解执行计划 通过观察EXPLAIN的结果，你可以知道如何给数据表添加索引使得执行计划使用索引从而加速 SQL 语句的执行速度；你也可以使用EXPLAIN来检查优化器是否选择了最优的顺序来 JOIN 数据表 详见：https://pingcap.com/docs-cn/v3.0/query-execution-plan/ （1）EXPLAIN输出格式 目前 TiDB 的EXPLAIN会输出 4 列，分别是：id，count，task，operator info。执行计划中每个算子都...
TiDB性能调优的常用方法
互联网知识分享
10-07 992
通过硬件资源调优、配置参数调优、SQL优化和数据模型优化等方法，可以显著提升TiDB的性能和吞吐量。合理选择和使用这些调优方法，可以根据具体场景和需求来优化TiDB集群的性能。调优是提高TiDB性能的关键步骤，通过优化配置参数、调整硬件资源、优化SQL语句以及合理设计数据模型等方法，可以显著提升TiDB的性能和吞吐量。索引是加速查询的关键，通过合理设计和使用索引，可以显著提升查询性能。磁盘和文件系统的性能对TiDB的读写速度有重要影响。选择合适的文件系统，如XFS或ext4，以提供更好的性能和稳定性。
TiDB 查询优化及调优系列（五）调优案例实践
TiDB_PingCAP 的博客
05-30 568
本文为「TiDB 查询优化及调优」系列文章的第五篇，也是最终篇。通过这个系列文章，我们详细介绍了 TiDB 优化器、查询计划、慢查询以及调优的理论知识，并在本章节中进行了实战的分享。希望通过这个系列文章，大家能够更加深入地理解 TiDB 优化器，并通过这些调优技巧更好地提升系统性能。
3.理解TiDB执行计划
ex-huh001的博客
11-18 4030
一、Explain EXPLAIN语句仅用于显示查询的执行计划，而不执行查询。EXPLAIN ANALYZE可执行查询，补充EXPLAIN语句。如果EXPLAIN的输出与预期结果不匹配，可考虑在查询的每个表上执行ANALYZE TABLE。 语句DESC和DESCRIBE是EXPLAIN的别名。EXPLAIN <tableName>的替代用法记录在SHOW [FULL] COLUMNS FROM下。 TiDB 支持EXPLAIN [options] F...
sheng的学习笔记-tidb框架原理
coldstarry的专栏
11-06 933
‌OLTP（联机事务处理）和‌OLAP（联机分析处理）定义‌OLTP‌：联机事务处理（Online Transaction Processing），主要用于日常事务处理，如银行交易、销售记录等，强调高吞吐量和实时处理。‌OLAP‌：联机分析处理（Online Analytical Processing），主要用于数据分析、决策支持，强调复杂查询和多维数据分析。‌数据处理方式‌OLTP‌：主要处理当前的、详细的数据，强调增删改查（CRUD）操作，数据更新频繁，响应时间短。‌OLAP。
07 Oracle数据库恢复基础解析：从检查点到归档，一步步构建数据安全防线
最新发布
超哥的博客
11-09 839
检查点是Oracle数据库中的一个特殊事件，它的作用是将内存中的数据块同步到磁盘上，以确保数据的持久性。简单来说，就是让数据库“记住”到目前为止所有的更改。Redo日志是Oracle用来记录所有数据更改的日志文件。每次对数据库进行修改时，都会先写入Redo日志，然后再写入数据文件。这样，即使系统崩溃，也能通过Redo日志恢复数据。当数据库运行在归档模式下时，一旦当前的Redo日志文件满，Oracle会将其复制到一个安全的存储位置，并标记为已归档。这样可以长期保留Redo日志，便于历史数据的恢复。
2024.11.6-Redis的事务与持久化
whisper_Java 的博客
11-06 781
MULTI、EXEC、DISCARD和WATCH 是 Redis 事务相关的命令。Redis的事务是将一系列待执行的指令存到一个Queue中，并使用exec执行事务。​--1. Redis事务是一个独立的隔离机制：事务中的所有命令都会序列化到queue、并按顺序地执行queue里的指令。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。​​multi: 用于开启事务，将待执行的命令放入到队列中exec命令:负责触发并执行事务中的所有命令：discard: 用于取消组队。
Redis - 事务
ketil27的博客
11-08 796
Redis 的事务和MySQL的事务概念上是类似的.都是把⼀系列操作绑定成⼀组.让这⼀组能够批量执 ⾏.弱化的原⼦性:redis没有"回滚机制".只能做到这些操作"批量执⾏".不能做到"⼀个失败就恢复到 初始状态".不保证⼀致性:不涉及"约束". 也没有回滚.MySQL的⼀致性体现的是运⾏事务前和运⾏后,结果都 是合理有效的,不会出现中间⾮法状态.不需要隔离性:也没有隔离级别,因为不会并发执⾏事务(redis单线程处理请求).
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

每天读点书学堂

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值