From 7d1b8804127e406e42af95b82153d345feb7b2ad Mon Sep 17 00:00:00 2001 From: JustWPH Date: Thu, 15 Jul 2021 12:05:32 +0800 Subject: [PATCH] fix typo error by zhlint(zh.md) (#6634) --- enable-tls-between-clients-and-servers.md | 4 +- encryption-at-rest.md | 2 +- error-codes.md | 4 +- explain-joins.md | 2 +- explain-mpp.md | 2 +- explain-partitions.md | 4 +- explain-subqueries.md | 2 +- exporting-grafana-snapshots.md | 2 +- expression-syntax.md | 2 +- garbage-collection-configuration.md | 4 +- garbage-collection-overview.md | 8 ++-- generate-self-signed-certificates.md | 2 +- get-started-with-tispark.md | 2 +- glossary.md | 2 +- grafana-overview-dashboard.md | 2 +- grafana-pd-dashboard.md | 4 +- grafana-tidb-dashboard.md | 12 +++--- grafana-tikv-dashboard.md | 8 ++-- hybrid-deployment-topology.md | 2 +- identify-expensive-queries.md | 2 +- identify-slow-queries.md | 6 +-- literal-values.md | 14 +++---- max-min-eliminate.md | 2 +- migrate-from-aurora-using-lightning.md | 2 +- migrate-from-mysql-dumpling-files.md | 2 +- migration-overview.md | 2 +- multi-data-centers-in-one-city-deployment.md | 2 +- mysql-compatibility.md | 8 ++-- optimistic-transaction.md | 2 +- optimizer-hints.md | 2 +- partition-pruning.md | 4 +- partitioned-table.md | 16 +++---- pd-configuration-file.md | 22 +++++----- pd-control.md | 14 +++---- post-installation-check.md | 2 +- predicate-push-down.md | 4 +- privilege-management.md | 2 +- production-deployment-using-tiup.md | 6 +-- quick-start-with-tidb.md | 2 +- read-historical-data.md | 4 +- scale-tidb-using-tiup.md | 6 +-- schedule-replicas-by-topology-labels.md | 10 ++--- schema-object-names.md | 2 +- shard-row-id-bits.md | 4 +- sql-mode.md | 6 +-- sql-physical-optimization.md | 2 +- sql-plan-management.md | 8 ++-- system-variables.md | 4 +- table-filter.md | 6 +-- ...e-data-centers-in-two-cities-deployment.md | 2 +- tidb-configuration-file.md | 16 +++---- tidb-control.md | 10 ++--- tidb-scheduling.md | 8 ++-- tidb-storage.md | 6 +-- tidb-troubleshooting-map.md | 42 +++++++++---------- tikv-configuration-file.md | 27 ++++++------ tikv-overview.md | 2 +- tispark-overview.md | 10 ++--- transaction-overview.md | 12 +++--- troubleshoot-cpu-issues.md | 2 +- troubleshoot-high-disk-io.md | 4 +- tune-tikv-thread-performance.md | 10 ++--- upgrade-tidb-using-tiup.md | 2 +- views.md | 4 +- whats-new-in-tidb-4.0.md | 12 +++--- 65 files changed, 203 insertions(+), 204 deletions(-) diff --git a/enable-tls-between-clients-and-servers.md b/enable-tls-between-clients-and-servers.md index 68324a74887c..5629fcadf573 100644 --- a/enable-tls-between-clients-and-servers.md +++ b/enable-tls-between-clients-and-servers.md @@ -20,7 +20,7 @@ TiDB 的加密连接支持默认是关闭的，必须在 TiDB 服务端通过配 1. TiDB 服务端配置开启加密连接的支持 2. 客户端指定使用加密连接 -另外，与 MySQL 一致，TiDB 加密连接是以单个连接为单位的，默认情况下是可选的。因而对于开启了加密连接支持的 TiDB 服务端，客户端既可以选择通过加密连接安全地连接到该 TiDB 服务端，也可以选择使用普通的非加密连接。如需强制要求客户端使用加密连接可以通过以下两种方式进行配置: +另外，与 MySQL 一致，TiDB 加密连接是以单个连接为单位的，默认情况下是可选的。因而对于开启了加密连接支持的 TiDB 服务端，客户端既可以选择通过加密连接安全地连接到该 TiDB 服务端，也可以选择使用普通的非加密连接。如需强制要求客户端使用加密连接可以通过以下两种方式进行配置： + 通过在启动参数中配置 `--require-secure-transport` 要求所有用户必须使用加密连接来连接到 TiDB。 + 通过在创建用户 (`create user`)，赋予权限 (`grant`) 或修改已有用户 (`alter user`) 时指定 `require ssl` 要求指定用户必须使用加密连接来连接 TiDB。以创建用户为例： @@ -91,7 +91,7 @@ MySQL 5.7 及以上版本自带的客户端默认尝试使用安全连接，若 若在 TiDB 服务端或 MySQL 客户端中未指定 `ssl-ca` 参数，则默认不会进行客户端或服务端身份验证，无法抵御中间人攻击，例如客户端可能会“安全地”连接到了一个伪装的服务端。可以在服务端和客户端中配置 `ssl-ca` 参数进行身份验证。一般情况下只需验证服务端身份，但也可以验证客户端身份进一步增强安全性。 -- 若要使 MySQL 客户端验证 TiDB 服务端身份，TiDB 服务端需至少配置 `ssl-cert` 和 `ssl-key` 参数，客户端需至少指定 `--ssl-ca` 参数，且 `--ssl-mode` 至少为 `VERIFY_CA`。必须确保 TiDB 服务端配置的证书（`ssl-cert`）是由客户端 `--ssl-ca` 参数所指定的 CA 所签发的，否则身份验证失败。 +- 若要使 MySQL 客户端验证 TiDB 服务端身份，TiDB 服务端需至少配置 `ssl-cert` 和 `ssl-key` 参数，客户端需至少指定 `--ssl-ca` 参数，且 `--ssl-mode` 至少为 `VERIFY_CA`。必须确保 TiDB 服务端配置的证书 (`ssl-cert`) 是由客户端 `--ssl-ca` 参数所指定的 CA 所签发的，否则身份验证失败。 - 若要使 TiDB 服务端验证 MySQL 客户端身份，TiDB 服务端需配置 `ssl-cert`、`ssl-key`、`ssl-ca` 参数，客户端需至少指定 `--ssl-cert`、`--ssl-key` 参数。必须确保服务端配置的证书和客户端配置的证书都是由服务端配置指定的 `ssl-ca` 签发的。 - 若要进行双向身份验证，请同时满足上述要求。 diff --git a/encryption-at-rest.md b/encryption-at-rest.md index 5a1624e4c366..338b42e286ad 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -59,7 +59,7 @@ region = "us-west-2" endpoint = "https://kms.us-west-2.amazonaws.com" ``` -`key-id` 指定 KMS CMK 的密钥 ID。`region` 为 KMS CMK 的 AWS 区域名。除非你使用非 AWS 提供的 AWS KMS 兼容服务， `endpoint` 通常无需指定。 +`key-id` 指定 KMS CMK 的密钥 ID。`region` 为 KMS CMK 的 AWS 区域名。除非你使用非 AWS 提供的 AWS KMS 兼容服务，`endpoint` 通常无需指定。 若要使用文件方式指定主密钥，主密钥配置应如下所示： diff --git a/error-codes.md b/error-codes.md index 8bcb789e5c4e..751fce535870 100644 --- a/error-codes.md +++ b/error-codes.md @@ -129,7 +129,7 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样 * Error Number: 8050 - 设置了不支持的权限类型，遇到该错误请参考[TiDB 权限说明](/privilege-management.md#tidb-各操作需要的权限)进行调整。 + 设置了不支持的权限类型，遇到该错误请参考 [TiDB 权限说明](/privilege-management.md#tidb-各操作需要的权限)进行调整。 * Error Number: 8051 @@ -259,7 +259,7 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样 * Error Number: 8200 - 尚不支持的 DDL 语法。请参考 [与 MySQL DDL 的兼容性](/mysql-compatibility.md#ddl-的限制)。 + 尚不支持的 DDL 语法。请参考[与 MySQL DDL 的兼容性](/mysql-compatibility.md#ddl-的限制)。 * Error Number: 8214 diff --git a/explain-joins.md b/explain-joins.md index c9df689e88ea..b463258f321d 100644 --- a/explain-joins.md +++ b/explain-joins.md @@ -7,7 +7,7 @@ summary: 了解 TiDB 中 EXPLAIN 语句返回的执行计划信息。 在 TiDB 中，SQL 优化器需要确定数据表的连接顺序，且要判断对于某条特定的 SQL 语句，哪一种 Join 算法最为高效。 -本文档使用的示例数据如下: +本文档使用的示例数据如下： {{< copyable "sql" >}} diff --git a/explain-mpp.md b/explain-mpp.md index b8117ecc2d75..a0e4bfdb1ab6 100644 --- a/explain-mpp.md +++ b/explain-mpp.md @@ -7,7 +7,7 @@ summary: 了解 TiDB 中 EXPLAIN 语句返回的执行计划信息。 TiDB 支持使用 [MPP 模式](/tiflash/use-tiflash.md#使用-mpp-模式)来执行查询。在 MPP 执行模式下，SQL 优化器会生成 MPP 的执行计划。注意 MPP 模式仅对有 [TiFlash](/tiflash/tiflash-overview.md) 副本的表生效。 -本文档使用的示例数据如下: +本文档使用的示例数据如下： {{< copyable "sql" >}} diff --git a/explain-partitions.md b/explain-partitions.md index 635efdabf6d6..35fa20de2a46 100644 --- a/explain-partitions.md +++ b/explain-partitions.md @@ -7,7 +7,7 @@ summary: 了解 TiDB 中 EXPLAIN 语句返回的执行计划信息。 使用 `EXPLAIN` 语句可以查看 TiDB 在执行查询时需要访问的分区。由于存在[分区裁剪](/partition-pruning.md)，所显示的分区通常只是所有分区的一个子集。本文档介绍了常见分区表的一些优化方式，以及如何解读 `EXPLAIN` 语句返回的执行计划信息。 -本文档所使用的示例数据如下: +本文档所使用的示例数据如下： {{< copyable "sql" >}} @@ -76,7 +76,7 @@ EXPLAIN SELECT COUNT(*) FROM t1 WHERE d = '2017-06-01'; 由上述 `EXPLAIN` 结果可知，从最末尾的 `—TableFullScan_19` 算子开始，再返回到根部的 `StreamAgg_21` 算子的执行过程如下： -* TiDB 成功地识别出只需要访问一个分区（`p2017`），并将该信息在 `access object` 列中注明。 +* TiDB 成功地识别出只需要访问一个分区 (`p2017`)，并将该信息在 `access object` 列中注明。 * `└─TableFullScan_19` 算子先对整个分区进行扫描，然后执行 `└─Selection_20` 算子筛选起始日期为 `2017-06-01 00:00:00.000000` 的行。 * 之后，`└─Selection_20` 算子匹配的行在 Coprocessor 中进行流式聚合，Coprocessor 本身就可以理解聚合函数 `count`。 * 每个 Coprocessor 请求会发送一行数据给 TiDB 的 `└─TableReader_22` 算子，然后将数据在 `StreamAgg_21` 算子下进行流式聚合，再将一行数据返回给客户端。 diff --git a/explain-subqueries.md b/explain-subqueries.md index e299f9ca7857..546a8d57235e 100644 --- a/explain-subqueries.md +++ b/explain-subqueries.md @@ -7,7 +7,7 @@ summary: 了解 TiDB 中 EXPLAIN 语句返回的执行计划信息。 TiDB 会执行多种[子查询相关的优化](/subquery-optimization.md)，以提升子查询的执行性能。本文档介绍一些常见子查询的优化方式，以及如何解读 `EXPLAIN` 语句返回的执行计划信息。 -本文档所使用的示例表数据如下: +本文档所使用的示例表数据如下： ```sql CREATE TABLE t1 (id BIGINT NOT NULL PRIMARY KEY auto_increment, pad1 BLOB, pad2 BLOB, pad3 BLOB, int_col INT NOT NULL DEFAULT 0); diff --git a/exporting-grafana-snapshots.md b/exporting-grafana-snapshots.md index dc0f1230d5e1..47b4d3672af3 100644 --- a/exporting-grafana-snapshots.md +++ b/exporting-grafana-snapshots.md @@ -9,7 +9,7 @@ summary: 了解如何将 Grafana 监控数据导出为快照以及如何将快 ## 使用方法 -可以通过访问 来使用 MetricsTool。它主要提供以下三种功能： +可以通过访问 `` 来使用 MetricsTool。它主要提供以下三种功能： * **导出快照**：提供一段在浏览器开发者工具上运行的用户脚本。你可以使用这个脚本在任意 Grafana v6.x.x 服务器上下载当前 Dashboard 中所有可见面板的快照。 diff --git a/expression-syntax.md b/expression-syntax.md index 0709e62c37e8..549b9aae184b 100644 --- a/expression-syntax.md +++ b/expression-syntax.md @@ -12,7 +12,7 @@ aliases: ['/docs-cn/dev/expression-syntax/','/docs-cn/dev/reference/sql/language + 标识符，可参考[模式对象名](/schema-object-names.md)。 + 谓词、数值、字符串、日期表达式等，这些类型的[字面值](/literal-values.md)也是表达式。 -+ 函数调用，窗口函数等。可参考[函数和操作符概述](/functions-and-operators/functions-and-operators-overview.md) 和 [窗口函数](/functions-and-operators/window-functions.md)。 ++ 函数调用，窗口函数等。可参考[函数和操作符概述](/functions-and-operators/functions-and-operators-overview.md)和[窗口函数](/functions-and-operators/window-functions.md)。 + 其他，包括 paramMarker（即 `?`）、系统变量和用户变量、CASE 表达式等。 以下规则是表达式的语法，该语法基于 TiDB parser 的 [parser.y](https://github.com/pingcap/parser/blob/master/parser.y) 文件中所定义的规则。此外，下列语法图的可导航版本请参考 [TiDB SQL 语法图](https://pingcap.github.io/sqlgram/#Expression)。 diff --git a/garbage-collection-configuration.md b/garbage-collection-configuration.md index 50e7117c2bcf..e2cc894d988e 100644 --- a/garbage-collection-configuration.md +++ b/garbage-collection-configuration.md @@ -5,7 +5,7 @@ aliases: ['/docs-cn/dev/garbage-collection-configuration/','/docs-cn/dev/referen # GC 配置 -你可以通过以下系统变量进行 GC 配置: +你可以通过以下系统变量进行 GC 配置： * [`tidb_gc_enable`](/system-variables.md#tidb_gc_enable-从-v50-版本开始引入) * [`tidb_gc_run_interval`](/system-variables.md#tidb_gc_run_interval-从-v50-版本开始引入) @@ -29,7 +29,7 @@ tikv-ctl --host=ip:port modify-tikv-config -m server -n gc.max_write_bytes_per_s TiDB 5.0 及之后的版本不再需要向各个 TiKV Region 都发送触发 GC 的请求，因此不再提供 `CENTRAL` GC 模式的支持，取而代之的是效率更高的 `DISTRIBUTED` GC 模式 （自 TiDB 3.0 起的默认 GC 模式）。 -如果要了解 TiDB 历史版本中 GC 配置的变化信息，请使用左侧导航栏中的 _TIDB 版本选择器_ 切换到本文档的历史版本。 +如果要了解 TiDB 历史版本中 GC 配置的变化信息，请使用左侧导航栏中的 _"TIDB 版本选择器"_ 切换到本文档的历史版本。 ## GC in Compaction Filter 机制 diff --git a/garbage-collection-overview.md b/garbage-collection-overview.md index 61a2705866d6..efc7fb8020db 100644 --- a/garbage-collection-overview.md +++ b/garbage-collection-overview.md @@ -13,9 +13,9 @@ TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新 GC 会被定期触发。每次 GC 时，首先，TiDB 会计算一个称为 safe point 的时间戳，接下来 TiDB 会在保证 safe point 之后的快照全部拥有正确数据的前提下，删除更早的过期数据。每一轮 GC 分为以下三个步骤： -1. Resolve Locks。该阶段会对所有 Region 扫描 safe point 之前的锁，并清理这些锁。 -2. Delete Ranges。该阶段快速地删除由于 `DROP TABLE`/`DROP INDEX` 等操作产生的整区间的废弃数据。 -3. Do GC。该阶段每个 TiKV 节点将会各自扫描该节点上的数据，并对每一个 key 删除其不再需要的旧版本。 +1. "Resolve Locks" 阶段会对所有 Region 扫描 safe point 之前的锁，并清理这些锁。 +2. "Delete Ranges" 阶段快速地删除由于 `DROP TABLE`/`DROP INDEX` 等操作产生的整区间的废弃数据。 +3. "Do GC" 阶段每个 TiKV 节点将会各自扫描该节点上的数据，并对每一个 key 删除其不再需要的旧版本。 默认配置下，GC 每 10 分钟触发一次，每次 GC 会保留最近 10 分钟内的数据（即默认 GC life time 为 10 分钟，safe point 的计算方式为当前时间减去 GC life time）。如果一轮 GC 运行时间太久，那么在一轮 GC 完成之前，即使到了下一次触发 GC 的时间也不会开始下一轮 GC。另外，为了使持续时间较长的事务能在超过 GC life time 之后仍然可以正常运行，safe point 不会超过正在执行中的事务的开始时间 (start_ts)。 @@ -50,4 +50,4 @@ Resolve Locks 有两种执行模式： > **注意：** > -> 从 TiDB 5.0 版本起，`CENTRAL` GC 模式（需要 TiDB 服务器发送 GC 请求到各个 Region）已经废弃， Do GC 这一步将只以 `DISTRIBUTED` GC 模式（从 TiDB 3.0 版起的默认模式）运行。 +> 从 TiDB 5.0 版本起，`CENTRAL` GC 模式（需要 TiDB 服务器发送 GC 请求到各个 Region）已经废弃，Do GC 这一步将只以 `DISTRIBUTED` GC 模式（从 TiDB 3.0 版起的默认模式）运行。 diff --git a/generate-self-signed-certificates.md b/generate-self-signed-certificates.md index 03aec7b4c782..5828e510ec74 100644 --- a/generate-self-signed-certificates.md +++ b/generate-self-signed-certificates.md @@ -36,7 +36,7 @@ apt install openssl yum install openssl ``` -也可以参考 OpenSSL 官方的[下载文档](https://www.openssl.org/source/) 进行安装。 +也可以参考 OpenSSL 官方的[下载文档](https://www.openssl.org/source/)进行安装。 ## 生成 CA 证书 diff --git a/get-started-with-tispark.md b/get-started-with-tispark.md index d0b822a173d1..b8fb81bd5180 100644 --- a/get-started-with-tispark.md +++ b/get-started-with-tispark.md @@ -23,7 +23,7 @@ aliases: ['/docs-cn/dev/get-started-with-tispark/','/docs-cn/dev/how-to/get-star ### 在 TiDB 实例上安装 JDK -在 [Oracle JDK 官方下载页面](http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html) 下载 JDK 1.8 当前最新版，本示例中下载的版本为 `jdk-8u141-linux-x64.tar.gz`。 +在 [Oracle JDK 官方下载页面](http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html)下载 JDK 1.8 当前最新版，本示例中下载的版本为 `jdk-8u141-linux-x64.tar.gz`。 解压并根据您的 JDK 部署目录设置环境变量，编辑 `~/.bashrc` 文件，比如： diff --git a/glossary.md b/glossary.md index d09fe63ca2ae..1784c2466b7d 100644 --- a/glossary.md +++ b/glossary.md @@ -10,7 +10,7 @@ aliases: ['/docs-cn/dev/glossary/'] ### ACID -ACID 是指数据库管理系统在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特性：原子性 (atomicity)、一致性 (consistency)、隔离性（isolation）以及持久性（durability）。 +ACID 是指数据库管理系统在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特性：原子性 (atomicity)、一致性 (consistency)、隔离性 (isolation) 以及持久性 (durability)。 * 原子性 (atomicity) 指一个事务中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。TiDB 通过 Primary Key 所在 [Region](#regionpeerraft-group) 的原子性来保证分布式事务的原子性。 * 一致性 (consistency) 指在事务开始之前和结束以后，数据库的完整性没有被破坏。TiDB 在写入数据之前，会校验数据的一致性，校验通过才会写入内存并返回成功。 diff --git a/grafana-overview-dashboard.md b/grafana-overview-dashboard.md index c69665e4c35d..5510a78a90b7 100644 --- a/grafana-overview-dashboard.md +++ b/grafana-overview-dashboard.md @@ -67,7 +67,7 @@ aliases: ['/docs-cn/dev/grafana-overview-dashboard/','/docs-cn/dev/reference/key - scheduler pending commands：每个 TiKV 实例上 pending 命令的个数 - coprocessor executor count：TiKV 每秒收到的 coprocessor 操作数量，按照 coprocessor 类型统计 - coprocessor request duration：处理 coprocessor 读请求所花费的时间 -- raft store CPU：raftstore 线程的 CPU 使用率，线程数量默认为 2 (通过 `raftstore.store-pool-size` 配置)。如果单个线程使用率超过 80%，说明使用率很高 +- raft store CPU：raftstore 线程的 CPU 使用率，线程数量默认为 2（通过 `raftstore.store-pool-size` 配置）。如果单个线程使用率超过 80%，说明使用率很高 - Coprocessor CPU：coprocessor 线程的 CPU 使用率 ## System Info diff --git a/grafana-pd-dashboard.md b/grafana-pd-dashboard.md index 3af7956b314e..dc822e87b69e 100644 --- a/grafana-pd-dashboard.md +++ b/grafana-pd-dashboard.md @@ -72,7 +72,7 @@ aliases: ['/docs-cn/dev/grafana-pd-dashboard/','/docs-cn/dev/reference/key-monit - Store Write rate bytes：每个 TiKV 实例总的写入的流量 - Store Write rate keys：每个 TiKV 实例总的写入 keys - Hot cache write entry number：每个 TiKV 实例进入热点统计模块的 peer 的数量 -- Selector events： 热点调度中选择器的事件发生次数 +- Selector events：热点调度中选择器的事件发生次数 - Direction of hotspot move leader：热点调度中 leader 的调度方向，正数代表调入，负数代表调出 - Direction of hotspot move peer：热点调度中 peer 的调度方向，正数代表调入，负数代表调出 @@ -137,7 +137,7 @@ aliases: ['/docs-cn/dev/grafana-pd-dashboard/','/docs-cn/dev/reference/key-monit ## Heartbeat -- Heartbeat region event QPS：心跳处理 region 的 QPS， 包括更新缓存和持久化 +- Heartbeat region event QPS：心跳处理 region 的 QPS，包括更新缓存和持久化 - Region heartbeat report：TiKV 向 PD 发送的心跳个数 - Region heartbeat report error：TiKV 向 PD 发送的异常的心跳个数 - Region heartbeat report active：TiKV 向 PD 发送的正常的心跳个数 diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md index 823956b77e67..9d670f5b7698 100644 --- a/grafana-tidb-dashboard.md +++ b/grafana-tidb-dashboard.md @@ -76,11 +76,11 @@ aliases: ['/docs-cn/dev/grafana-tidb-dashboard/','/docs-cn/dev/reference/key-mon - Async Commit Transaction Counter：启用 Async commit 机制的事务数量，分为成功、失败两种 - Executor - - Parse Duration：SQL 语句解析耗时统计 - - Compile Duration：将解析后的 SQL AST 编译成执行计划耗时统计 - - Execution Duration：执行 SQL 语句执行计划耗时统计 - - Expensive Executor OPS：每秒消耗系统资源比较多的算子统计，包括 Merge Join，Hash Join，Index Look Up Join，Hash Agg，Stream Agg，Sort，TopN 等 - - Queries Using Plan Cache OPS：每秒使用 Plan Cache 的查询数量统计 + - Parse Duration：SQL 语句解析耗时统计。 + - Compile Duration：将解析后的 SQL AST 编译成执行计划耗时统计。 + - Execution Duration：执行 SQL 语句执行计划耗时统计。 + - Expensive Executor OPS：每秒消耗系统资源比较多的算子统计。包括 Merge Join、Hash Join、Index Look Up Join、Hash Agg、Stream Agg、Sort、TopN 等。 + - Queries Using Plan Cache OPS：每秒使用 Plan Cache 的查询数量统计。 - Distsql - Distsql Duration：Distsql 处理的时长 @@ -153,7 +153,7 @@ aliases: ['/docs-cn/dev/grafana-tidb-dashboard/','/docs-cn/dev/reference/key-mon - GC - Worker Action OPM：GC 相关操作的数量，包括 run\_job，resolve\_lock，delete\_range 等操作 - Duration 99：GC 相关操作的耗时统计 - - Config：GC 的数据保存时长（life time）和 GC 运行间隔（run interval）配置 + - Config：GC 的数据保存时长 (life time) 和 GC 运行间隔 (run interval) 配置 - GC Failure OPM：GC 相关操作失败数量统计 - Delete Range Failure OPM：Delete range 失败的次数 - Too Many Locks Error OPM：GC 清锁过多错误的数量 diff --git a/grafana-tikv-dashboard.md b/grafana-tikv-dashboard.md index 73f73e78de8a..ac2929a308a3 100644 --- a/grafana-tikv-dashboard.md +++ b/grafana-tikv-dashboard.md @@ -9,7 +9,7 @@ aliases: ['/docs-cn/dev/grafana-tikv-dashboard/','/docs-cn/dev/reference/key-mon 目前 Grafana Dashboard 整体分为 PD、TiDB、TiKV、Node\_exporter、Overview 等。 -对于日常运维，我们通过观察 **TiKV-Details** 面板上的指标，可以了解 TiKV 当前的状态。根据 [性能地图](https://asktug.com/_/tidb-performance-map/#/) 可以检查集群的状态是否符合预期。 +对于日常运维，我们通过观察 **TiKV-Details** 面板上的指标，可以了解 TiKV 当前的状态。根据[性能地图](https://asktug.com/_/tidb-performance-map/#/)可以检查集群的状态是否符合预期。 以下为 **TiKV-Details** 默认的监控信息： @@ -227,7 +227,7 @@ aliases: ['/docs-cn/dev/grafana-tikv-dashboard/','/docs-cn/dev/reference/key-mon - TiDB GC seconds：TiDB 执行 GC 花费的时间 - TiDB GC worker actions：TiDB GC worker 的不同 action 的个数 - TiKV AutoGC Working：Auto GC 管理器的工作状态 -- ResolveLocks Progress：GC 第一阶段（ResolveLocks）的进度 +- ResolveLocks Progress：GC 第一阶段 (ResolveLocks) 的进度 - TiKV Auto GC Progress：GC 第二阶段的进度 - GC speed：GC 每秒删除的 key 的数量 - TiKV Auto GC SafePoint：TiKV GC 的 safe point 的数值，safe point 为当前 GC 的时间戳 @@ -305,9 +305,9 @@ aliases: ['/docs-cn/dev/grafana-tikv-dashboard/','/docs-cn/dev/reference/key-mon - Keys flow：不同操作造成的 key 的流量 - Total keys：每个 CF 中 key 的个数 - Read flow：不同读操作的流量 -- Bytes / Read：每次读的大小 +- Bytes/Read：每次读的大小 - Write flow：不同写操作的流量 -- Bytes / Write：每次写的大小 +- Bytes/Write：每次写的大小 - Compaction flow：compaction 相关的流量 - Compaction pending bytes：等待 compaction 的大小 - Read amplification：每个 TiKV 实例的读放大 diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index 1e1eaed2238a..1ed1ce10dc44 100644 --- a/hybrid-deployment-topology.md +++ b/hybrid-deployment-topology.md @@ -100,6 +100,6 @@ aliases: ['/docs-cn/dev/hybrid-deployment-topology/'] > **注意：** > > - 编辑配置文件模版时，注意修改必要参数、IP、端口及目录。 -> - 各个组件的 deploy_dir，默认会使用 global 中的 `/-`。例如 tidb 端口指定 4001，则 deploy_dir 默认为 /tidb-deploy/tidb-4001。因此，在多实例场景下指定非默认端口时，无需再次指定目录。 +> - 各个组件的 deploy_dir，默认会使用 global 中的 `/-`。例如 tidb 端口指定 4001，则 deploy_dir 默认为 '/tidb-deploy/tidb-4001'。因此，在多实例场景下指定非默认端口时，无需再次指定目录。 > - 无需手动创建配置文件中的 `tidb` 用户，TiUP cluster 组件会在部署主机上自动创建该用户。可以自定义用户，也可以和中控机的用户保持一致。 > - 如果部署目录配置为相对路径，会部署在用户家目录下。 diff --git a/identify-expensive-queries.md b/identify-expensive-queries.md index e5b33790115a..fb64bfc3e440 100644 --- a/identify-expensive-queries.md +++ b/identify-expensive-queries.md @@ -5,7 +5,7 @@ aliases: ['/docs-cn/dev/identify-expensive-queries/','/docs-cn/dev/how-to/mainta # 定位消耗系统资源多的查询 -TiDB 会将执行时间超过 [`tidb_expensive_query_time_threshold`](/system-variables.md#tidb_expensive_query_time_threshold) 限制（默认值为 60s），或使用内存超过 [`mem-quota-query`](/tidb-configuration-file.md#mem-quota-query) 限制（默认值为 1 GB）的语句输出到 [tidb-server 日志文件](/tidb-configuration-file.md#logfile)（默认文件为 “tidb.log”）中，用于在语句执行结束前定位消耗系统资源多的查询语句（以下简称为 expensive query），帮助用户分析和解决语句执行的性能问题。 +TiDB 会将执行时间超过 [`tidb_expensive_query_time_threshold`](/system-variables.md#tidb_expensive_query_time_threshold) 限制（默认值为 60s），或使用内存超过 [`mem-quota-query`](/tidb-configuration-file.md#mem-quota-query) 限制（默认值为 1 GB）的语句输出到 [tidb-server 日志文件](/tidb-configuration-file.md#logfile)（默认文件为 "tidb.log"）中，用于在语句执行结束前定位消耗系统资源多的查询语句（以下简称为 expensive query），帮助用户分析和解决语句执行的性能问题。 注意，expensive query 日志和[慢查询日志](/identify-slow-queries.md)的区别是，慢查询日志是在语句执行完后才打印，expensive query 日志可以将正在执行的语句的相关信息打印出来。当一条语句在执行过程中达到资源使用阈值时（执行时间/使用内存量），TiDB 会即时将这条语句的相关信息写入日志。 diff --git a/identify-slow-queries.md b/identify-slow-queries.md index d370cd5e4a34..16963da4f7a8 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -60,7 +60,7 @@ Slow Query 基础信息： * `Is_internal`：表示是否为 TiDB 内部的 SQL 语句。`true` 表示 TiDB 系统内部执行的 SQL 语句，`false` 表示用户执行的 SQL 语句。 * `Index_ids`：表示语句涉及到的索引的 ID。 * `Succ`：表示语句是否执行成功。 -* `Backoff_time`：表示语句遇到需要重试的错误时在重试前等待的时间，常见的需要重试的错误有以下几种：遇到了 lock、Region 分裂、`tikv server is busy`。 +* `Backoff_time`：表示语句遇到需要重试的错误时在重试前等待的时间。常见的需要重试的错误有以下几种：遇到了 lock、Region 分裂、`tikv server is busy`。 * `Plan`：表示语句的执行计划，用 `select tidb_decode_plan('xxx...')` SQL 语句可以解析出具体的执行计划。 * `Prepared`：表示这个语句是否是 `Prepare` 或 `Execute` 的请求。 * `Plan_from_cache`：表示这个语句是否命中了执行计划缓存。 @@ -150,7 +150,7 @@ set @@tidb_enable_collect_execution_info=0; ## 慢日志内存映射表 -用户可通过查询 `INFORMATION_SCHEMA.SLOW_QUERY` 表来查询慢查询日志中的内容，表中列名和慢日志中字段名一一对应，表结构可查看 [`SLOW_QUERY` 表](/information-schema/information-schema-slow-query.md) 中的介绍。 +用户可通过查询 `INFORMATION_SCHEMA.SLOW_QUERY` 表来查询慢查询日志中的内容，表中列名和慢日志中字段名一一对应，表结构可查看 [`SLOW_QUERY` 表](/information-schema/information-schema-slow-query.md)中的介绍。 > **注意：** > @@ -206,7 +206,7 @@ TiDB 4.0 中新增了 [`CLUSTER_SLOW_QUERY`](/information-schema/information-sch 关于查询 `CLUSTER_SLOW_QUERY` 表，TiDB 会把相关的计算和判断下推到其他节点执行，而不是把其他节点的慢查询数据都取回来在一台 TiDB 上执行。 -## 查询 `SLOW_QUERY` / `CLUSTER_SLOW_QUERY` 示例 +## 查询 `SLOW_QUERY`/`CLUSTER_SLOW_QUERY` 示例 ### 搜索 Top N 的慢查询 diff --git a/literal-values.md b/literal-values.md index 48a24226f390..9d1910bb4767 100644 --- a/literal-values.md +++ b/literal-values.md @@ -92,11 +92,11 @@ integer 可以包括 `.` 作为小数点分隔，数字前可以有 `-` 或者 ` ## Date and Time Literals -Date 跟 Time 字面值有几种格式，例如用字符串表示，或者直接用数字表示。在 TiDB 里面，当 TiDB 期望一个 Date 的时候，它会把 `'2017-08-24'`， `'20170824'`，`20170824` 当做是 Date。 +Date 跟 Time 字面值有几种格式，例如用字符串表示，或者直接用数字表示。在 TiDB 里面，当 TiDB 期望一个 Date 的时候，它会把 `'2017-08-24'`，`'20170824'`，`20170824` 当做是 Date。 TiDB 的 Date 值有以下几种格式： -* `'YYYY-MM-DD'` 或者 `'YY-MM-DD'`，这里的 `-` 分隔符并不是严格的，可以是任意的标点符号。比如 `'2017-08-24'`，`'2017&08&24'`， `'2012@12^31'` 都是一样的。唯一需要特别对待的是 '.' 号，它被当做是小数点，用于分隔整数和小数部分。 +* `'YYYY-MM-DD'` 或者 `'YY-MM-DD'`，这里的 `-` 分隔符并不是严格的，可以是任意的标点符号。比如 `'2017-08-24'`，`'2017&08&24'`，`'2012@12^31'` 都是一样的。唯一需要特别对待的是 '.' 号，它被当做是小数点，用于分隔整数和小数部分。 Date 和 Time 部分可以被 'T' 分隔，它的作用跟空格符是一样的，例如 `2017-8-24 10:42:00` 跟 `2017-8-24T10:42:00` 是一样的。 @@ -112,7 +112,7 @@ DATETIME 或者 TIMESTAMP 值可以接一个小数部分，用来表示微秒（ 对于小于 10 的 month 或者 day 值，`'2017-8-4'` 跟 `'2017-08-04'` 是一样的。对于 Time 也是一样，比如 `'2017-08-24 1:2:3'` 跟 `'2017-08-24 01:02:03'`是一样的。 -在需要 Date 或者 Time 的语境下, 对于数值，TiDB 会根据数值的长度来选定指定的格式： +在需要 Date 或者 Time 的语境下，对于数值，TiDB 会根据数值的长度来选定指定的格式： * 6 个数字，会被解释为 `YYMMDD`。 * 12 个数字，会被解释为 `YYMMDDHHMMSS`。 @@ -121,7 +121,7 @@ DATETIME 或者 TIMESTAMP 值可以接一个小数部分，用来表示微秒（ 对于 Time 类型，TiDB 用以下格式来表示： -* `'D HH:MM:SS'`，或者 `'HH:MM:SS'`，`'HH:MM'`，`'D HH:MM'`，`'D HH'`，`'SS'`，这里的 D 表示 days，合法的范围是 `0-34`。 +* `'D HH:MM:SS'`，或者 `'HH:MM:SS'`，`'HH:MM'`，`'D HH:MM'`，`'D HH'`，`'SS'`。这里的 D 表示 days，合法的范围是 `0-34`。 * 数值 `HHMMSS`，例如 `231010` 被解释为`'23:10:10'`。 * 数值 `SS`，`MMSS`，`HHMMSS` 都是可以被当做 Time。 @@ -152,7 +152,7 @@ SELECT TRUE, true, tRuE, FALSE, FaLsE, false; 十六进制字面值是有 `X` 和 `0x` 前缀的字符串，后接表示十六进制的数字。注意 `0x` 是大小写敏感的，不能表示为 `0X`。 -例: +例如： ``` X'ac12' @@ -243,8 +243,8 @@ SELECT X'54694442'; 非法的 Bit-value： -* b'2' (2 不是二进制数值, 必须为 0 或 1) -* 0B01 (0B 必须是小写 0b) +* `b'2'`（2 不是二进制数值，必须为 0 或 1） +* `0B01`（0B 必须是小写 0b） 默认情况，位值字面值是一个二进制字符串。 diff --git a/max-min-eliminate.md b/max-min-eliminate.md index 7acc17101dd1..5a468af23801 100644 --- a/max-min-eliminate.md +++ b/max-min-eliminate.md @@ -37,7 +37,7 @@ select max(a) from (select a from t where a is not null order by a desc limit 1) 这个新的 SQL 语句在 `a` 列存在索引（或 `a` 列是某个联合索引的前缀）时，能够利用索引只扫描一行数据来得到最大或者最小值，从而避免对整个表的扫描。 -上述例子最终得到的执行计划如下: +上述例子最终得到的执行计划如下： ``` mysql> explain select max(a) from t; diff --git a/migrate-from-aurora-using-lightning.md b/migrate-from-aurora-using-lightning.md index 22664a8520e3..e2aa0898c295 100644 --- a/migrate-from-aurora-using-lightning.md +++ b/migrate-from-aurora-using-lightning.md @@ -19,7 +19,7 @@ summary: 了解如何使用 TiDB Lightning 从 Amazon Aurora MySQL 迁移全量 根据部署方式不同，按如下步骤编辑配置文件 `tidb-lighting.toml`。 -1. 将 配置文件中 `[mydumper]` 部分的 `data-source-dir` 设置为[第一步](#第一步从-aurora-导出全量数据至-amazon-s3)导出的 S3 Bucket 路径。 +1. 将配置文件中 `[mydumper]` 部分的 `data-source-dir` 设置为[第一步](#第一步从-aurora-导出全量数据至-amazon-s3)导出的 S3 Bucket 路径。 ``` [mydumper] diff --git a/migrate-from-mysql-dumpling-files.md b/migrate-from-mysql-dumpling-files.md index 99ce25de20bd..ff41f2583a0f 100644 --- a/migrate-from-mysql-dumpling-files.md +++ b/migrate-from-mysql-dumpling-files.md @@ -15,7 +15,7 @@ aliases: ['/docs-cn/dev/migrate-from-mysql-mydumper-files/','/zh/tidb/dev/migrat > **注意：** > > - 如果选用 Local-backend 来导入数据，导入期间集群无法提供正常的服务，速度更快，适用于导入大量的数据（TB 以上级别）。 -> - 如果选用 TiDB-backend 来导入数据，导入期间集群可以正常提供服务, 但相对导入速度较慢。 +> - 如果选用 TiDB-backend 来导入数据，导入期间集群可以正常提供服务，但相对导入速度较慢。 > - 二者的具体差别参见 [TiDB Lightning Backend](/tidb-lightning/tidb-lightning-backends.md)。 ## 第 2 步：配置 TiDB Lightning 的数据源 diff --git a/migration-overview.md b/migration-overview.md index 3264cb07ab26..f40f1ff5769b 100644 --- a/migration-overview.md +++ b/migration-overview.md @@ -10,7 +10,7 @@ aliases: ['/docs-cn/dev/migration-overview/','/docs-cn/dev/data-migration-route' ## 从 Aurora 迁移到 TiDB -在云环境下，可以直接通过 Aurora Snapshot 导出的方式，将全量数据迁移至 TiDB。详细可参考 [使用 TiDB Lightning 从 Amazon Aurora MySQL 迁移全量数据](/migrate-from-aurora-using-lightning.md)。 +在云环境下，可以直接通过 Aurora Snapshot 导出的方式，将全量数据迁移至 TiDB。详细可参考[使用 TiDB Lightning 从 Amazon Aurora MySQL 迁移全量数据](/migrate-from-aurora-using-lightning.md)。 ## 从 MySQL 迁移到 TiDB diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index ff77687cca6e..8b49e08ba405 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -92,7 +92,7 @@ TiKV 是一个 Multi-Raft 系统，其数据按 Region（默认 96M）切分， 由于 3 副本的 Raft Group 只能容忍 1 副本故障，当集群被扩容到 N 个 TiKV 实例时，这个集群依然只能容忍一个 TiKV 实例的故障。2 个 TiKV 实例的故障可能会导致某些 Region 丢失多个副本，整个集群的数据也不再完整，访问到这些 Region 上的数据的 SQL 请求将会失败。而 N 个 TiKV 实例中同时有两个发生故障的概率是远远高于 3 个 TiKV 中同时有两个发生故障的概率的，也就是说 Multi-Raft 系统集群扩容 TiKV 实例越多，其可用性是逐渐降低的。 -正因为 Multi-Raft TiKV 系统局限性， Labels 标签应运而出，其主要用于描述 TiKV 的位置信息。Label 信息随着部署或滚动更新操作刷新到 TiKV 的启动配置文件中，启动后的 TiKV 会将自己最新的 Label 信息上报给 PD，PD 根据用户登记的 Label 名称（也就是 Label 元信息），结合 TiKV 的拓扑进行 Region 副本的最优调度，从而提高系统可用性。 +正因为 Multi-Raft TiKV 系统局限性，Labels 标签应运而出，其主要用于描述 TiKV 的位置信息。Label 信息随着部署或滚动更新操作刷新到 TiKV 的启动配置文件中，启动后的 TiKV 会将自己最新的 Label 信息上报给 PD，PD 根据用户登记的 Label 名称（也就是 Label 元信息），结合 TiKV 的拓扑进行 Region 副本的最优调度，从而提高系统可用性。 #### TiKV Labels 样例规划 diff --git a/mysql-compatibility.md b/mysql-compatibility.md index 4a0d7d1f60d2..4114ce4afa55 100644 --- a/mysql-compatibility.md +++ b/mysql-compatibility.md @@ -6,7 +6,7 @@ aliases: ['/docs-cn/dev/mysql-compatibility/','/docs-cn/dev/reference/mysql-comp # 与 MySQL 兼容性对比 -- TiDB 100% 兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。MySQL 5.7 生态中的系统工具（PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader）、客户端等均适用于 TiDB。 +- TiDB 100% 兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。MySQL 5.7 生态中的系统工具 (PHPMyAdmin、Navicat、MySQL Workbench、 mysqldump、Mydumper/Myloader)、客户端等均适用于 TiDB。 - 但 TiDB 尚未支持一些 MySQL 功能，可能的原因如下： - 有更好的解决方案，例如 JSON 取代 XML 函数。 @@ -19,7 +19,7 @@ aliases: ['/docs-cn/dev/mysql-compatibility/','/docs-cn/dev/reference/mysql-comp > **注意：** > -> 本页内容仅涉及 MySQL 与 TiDB 的总体差异。关于[安全特性](/security-compatibility-with-mysql.md)、[悲观事务模型](/pessimistic-transaction.md#和-mysql-innodb-的差异) 相关的兼容信息请查看各自具体页面。 +> 本页内容仅涉及 MySQL 与 TiDB 的总体差异。关于[安全特性](/security-compatibility-with-mysql.md)、[悲观事务模型](/pessimistic-transaction.md#和-mysql-innodb-的差异)相关的兼容信息请查看各自具体页面。 ## 不支持的功能特性 @@ -108,7 +108,7 @@ TiDB 中，所有支持的 DDL 变更操作都是在线执行的。与 MySQL 相 ### `ANALYZE TABLE` -TiDB 中的[信息统计](/statistics.md#手动收集) 与 MySQL 中的有所不同：TiDB 中的信息统计会完全重构表的统计数据，语句执行过程较长，但在 MySQL/InnoDB 中，它是一个轻量级语句，执行过程较短。 +TiDB 中的[信息统计](/statistics.md#手动收集)与 MySQL 中的有所不同：TiDB 中的信息统计会完全重构表的统计数据，语句执行过程较长，但在 MySQL/InnoDB 中，它是一个轻量级语句，执行过程较短。 更多信息统计的差异请参阅 [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)。 @@ -152,7 +152,7 @@ TiDB 支持大部分 [SQL 模式](/sql-mode.md)。不支持的 SQL 模式如下 - SQL mode： + TiDB 默认：`ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION`。 - + MySQL 5.7 默认 与 TiDB 相同。 + + MySQL 5.7 默认与 TiDB 相同。 + MySQL 8.0 默认 `ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION`。 - `lower_case_table_names`： diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 466d9ed6c9c0..daa1d607a13b 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -22,7 +22,7 @@ aliases: ['/docs-cn/dev/optimistic-transaction/','/docs-cn/dev/reference/transac 1. 客户端开始一个事务。 - TiDB 从 PD 获取一个全局唯一递增的时间戳作为当前事务的唯一事务 ID，这里称为该事务的 `start_ts`。TiDB 实现了多版本并发控制（MVCC），因此 `start_ts` 同时也作为该事务获取的数据库快照版本。该事务只能读到此 `start_ts` 版本可以读到的数据。 + TiDB 从 PD 获取一个全局唯一递增的时间戳作为当前事务的唯一事务 ID，这里称为该事务的 `start_ts`。TiDB 实现了多版本并发控制 (MVCC)，因此 `start_ts` 同时也作为该事务获取的数据库快照版本。该事务只能读到此 `start_ts` 版本可以读到的数据。 2. 客户端发起读请求。 diff --git a/optimizer-hints.md b/optimizer-hints.md index 1732c8d9c66d..5a2eacbd9ade 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -23,7 +23,7 @@ Optimizer Hints 不区分大小写，通过 `/*+ ... */` 注释的形式跟在 ` SELECT /*+ USE_INDEX(t1, idx1), HASH_AGG(), HASH_JOIN(t1) */ count(*) FROM t t1, t t2 WHERE t1.a = t2.b; ``` -可以通过 [`Explain`](/sql-statements/sql-statement-explain.md) / [`Explain Analyze`](/sql-statements/sql-statement-explain-analyze.md) 语句的输出，来查看 Optimizer Hints 对查询执行计划的影响。 +可以通过 [`Explain`](/sql-statements/sql-statement-explain.md)/[`Explain Analyze`](/sql-statements/sql-statement-explain-analyze.md) 语句的输出，来查看 Optimizer Hints 对查询执行计划的影响。 如果 Optimizer Hints 包含语法错误或不完整，查询语句不会报错，而是按照没有 Optimizer Hints 的情况执行。如果 Hint 不适用于当前语句，TiDB 会返回 Warning，用户可以在查询结束后通过 `Show Warnings` 命令查看具体信息。 diff --git a/partition-pruning.md b/partition-pruning.md index 93f8268a99eb..a757ae9a925c 100644 --- a/partition-pruning.md +++ b/partition-pruning.md @@ -66,7 +66,7 @@ explain select * from t where x = 1; +-------------------------+----------+-----------+-----------------------+--------------------------------+ ``` -在这条 SQL 中，由条件 `x = 1` 可以知道所有结果均在一个分区上。数值 `1` 在经过 Hash 后，可以确定其在分区 `p1` 中。因此只需要扫描分区 `p1` ,而无需访问一定不会出现相关结果的 `p2` 、`p3` 、`p4` 分区。从执行计划来看，其中只出现了一个 `TableFullScan` 算子，且在 `access object` 中指定了 `p1` 分区，确认 `partition pruning` 生效了。 +在这条 SQL 中，由条件 `x = 1` 可以知道所有结果均在一个分区上。数值 `1` 在经过 Hash 后，可以确定其在分区 `p1` 中。因此只需要扫描分区 `p1`，而无需访问一定不会出现相关结果的 `p2` 、`p3` 、`p4` 分区。从执行计划来看，其中只出现了一个 `TableFullScan` 算子，且在 `access object` 中指定了 `p1` 分区，确认 `partition pruning` 生效了。 #### Hash 分区表上不能使用分区裁剪的场景 @@ -193,7 +193,7 @@ explain select * from t where x in(1,13); +-----------------------------+----------+-----------+-----------------------+--------------------------------+ ``` -在这条 SQL 中，由条件 `x in(1,13)` 可以知道所有结果只会分布在几个分区上。经过分析，发现所有 `x = 1` 的记录都在分区 `p0` 上, 所有 `x = 13` 的记录都在分区 `p2` 上，因此只需要访问 `p0`、`p2` 这两个分区， +在这条 SQL 中，由条件 `x in(1,13)` 可以知道所有结果只会分布在几个分区上。经过分析，发现所有 `x = 1` 的记录都在分区 `p0` 上，所有 `x = 13` 的记录都在分区 `p2` 上，因此只需要访问 `p0`、`p2` 这两个分区， ##### 场景二 diff --git a/partitioned-table.md b/partitioned-table.md index c3b2ab551e9f..f192036ee6a2 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -9,7 +9,7 @@ aliases: ['/docs-cn/dev/partitioned-table/','/docs-cn/dev/reference/sql/partitio ## 分区类型 -本节介绍 TiDB 中的分区类型。当前支持的类型包括 [Range 分区](#range-分区)、[List 分区](#list-分区)、[List COLUMNS 分区](#list-columns-分区) 和 [Hash 分区](#hash-分区)。Range 分区，List 分区和 List COLUMNS 分区可以用于解决业务中大量删除带来的性能问题，支持快速删除分区。Hash 分区则可以用于大量写入场景下的数据打散。 +本节介绍 TiDB 中的分区类型。当前支持的类型包括 [Range 分区](#range-分区)、[List 分区](#list-分区)、[List COLUMNS 分区](#list-columns-分区)和 [Hash 分区](#hash-分区)。Range 分区，List 分区和 List COLUMNS 分区可以用于解决业务中大量删除带来的性能问题，支持快速删除分区。Hash 分区则可以用于大量写入场景下的数据打散。 ### Range 分区 @@ -241,7 +241,7 @@ test> INSERT INTO t VALUES (7, 7); ERROR 1525 (HY000): Table has no partition for value 7 ``` -要忽略以上类型的错误，可以通过使用 `IGNORE` 关键字。使用该关键字后，就不会插入包含不匹配分区列值的行，但是会插入任何具有匹配值的行，并且不会报错: +要忽略以上类型的错误，可以通过使用 `IGNORE` 关键字。使用该关键字后，就不会插入包含不匹配分区列值的行，但是会插入任何具有匹配值的行，并且不会报错： ```sql test> TRUNCATE t; @@ -1018,7 +1018,7 @@ PARTITION BY HASH(col1 + col3) ERROR 1491 (HY000): A PRIMARY KEY must include all columns in the table's partitioning function ``` -原因是 `col1` 和 `col3` 出现在分区键中，但是几个唯一键定义并没有完全包含它们，做如下修改后语句即为合法: +原因是 `col1` 和 `col3` 出现在分区键中，但是几个唯一键定义并没有完全包含它们，做如下修改后语句即为合法： {{< copyable "sql" >}} @@ -1080,7 +1080,7 @@ PARTITION BY HASH( YEAR(col2) ) PARTITIONS 4; ``` -以上两个例子中，主键都没有包含分区表达式中的全部的列，在主键中补充缺失列后语句即为合法: +以上两个例子中，主键都没有包含分区表达式中的全部的列，在主键中补充缺失列后语句即为合法： {{< copyable "sql" >}} @@ -1351,7 +1351,7 @@ mysql> explain select * from t1 where id < 150; + 不能使用 Plan Cache（见以下示例一和示例二） + 不能使用 IndexJoin 的执行方式（见以下示例三和示例四） -**示例一**：以下示例在配置文件中开启 Plan Cache 功能，并在 `static` 模式下执行同一个查询两次： +**示例一**：以下示例在配置文件中开启 Plan Cache 功能，并在 `static` 模式下执行同一个查询两次。 {{< copyable "sql" >}} @@ -1383,7 +1383,7 @@ mysql> select @@last_plan_from_cache; `last_plan_from_cache` 变量可以显示上一次查询是否命中 Plan Cache。从以上示例一可知，在 `static` 模式下，即使在分区表上执行同一个查询多次，也不会命中 Plan Cache。 -**示例二**：以下示例在 `dynamic` 模式下执行与示例一相同的操作： +**示例二**：以下示例在 `dynamic` 模式下执行与示例一相同的操作。 {{< copyable "sql" >}} @@ -1412,7 +1412,7 @@ mysql> select @@last_plan_from_cache; 由示例二结果可知，开启 `dynamic` 模式后，分区表查询能命中 Plan Cache 。 -**示例三**：以下示例在 `static` 模式下尝试执行计划带 IndexJoin 的查询： +**示例三**：以下示例在 `static` 模式下尝试执行计划带 IndexJoin 的查询。 {{< copyable "sql" >}} @@ -1450,7 +1450,7 @@ mysql> explain select /*+ TIDB_INLJ(t1, t2) */ t1.* from t1, t2 where t2.code = 从以上示例三结果可知，即使使用了 `TIDB_INLJ` 的 hint，也无法使得带分区表的查询选上带 IndexJoin 的执行计划。 -**示例四**：以下示例在 `dynamic` 模式下尝试执行计划带 IndexJoin 的查询： +**示例四**：以下示例在 `dynamic` 模式下尝试执行计划带 IndexJoin 的查询。 {{< copyable "sql" >}} diff --git a/pd-configuration-file.md b/pd-configuration-file.md index 51292163c88c..204cfe12fb1b 100644 --- a/pd-configuration-file.md +++ b/pd-configuration-file.md @@ -38,7 +38,7 @@ PD 配置文件比命令行参数支持更多的选项。你可以在 [conf/conf ### `peer-urls` + PD 节点监听其他 PD 节点的 URL 列表。 -+ 默认: `"http://127.0.0.1:2380"` ++ 默认：`"http://127.0.0.1:2380"` + 如果部署一个集群，peer URLs 必须指定当前主机的 IP 地址，例如 `"http://192.168.100.113:2380"`，如果是运行在 Docker 则需要指定为 `"http://0.0.0.0:2380"`。 ### `advertise-peer-urls` @@ -123,7 +123,7 @@ PD 配置文件比命令行参数支持更多的选项。你可以在 [conf/conf ### `format` -+ 日志格式，可指定为"text"，"json"， "console"。 ++ 日志格式，可指定为"text"，"json"，"console"。 + 默认值：text ### `disable-timestamp` @@ -145,13 +145,13 @@ PD 配置文件比命令行参数支持更多的选项。你可以在 [conf/conf ### `max-days` + 日志保留的最长天数。 -+ 默认: 28 ++ 默认：28 + 最小值为 1 ### `max-backups` + 日志文件保留的最大个数。 -+ 默认: 7 ++ 默认：7 + 最小值为 1 ## metric @@ -161,7 +161,7 @@ PD 配置文件比命令行参数支持更多的选项。你可以在 [conf/conf ### `interval` + 向 Prometheus 推送监控指标数据的间隔时间。 -+ 默认: 15s ++ 默认：15s ## schedule @@ -170,27 +170,27 @@ PD 配置文件比命令行参数支持更多的选项。你可以在 [conf/conf ### `max-merge-region-size` + 控制 Region Merge 的 size 上限，当 Region Size 大于指定值时 PD 不会将其与相邻的 Region 合并。 -+ 默认: 20 ++ 默认：20 ### `max-merge-region-keys` + 控制 Region Merge 的 key 上限，当 Region key 大于指定值时 PD 不会将其与相邻的 Region 合并。 -+ 默认: 200000 ++ 默认：200000 ### `patrol-region-interval` + 控制 replicaChecker 检查 Region 健康状态的运行频率，越短则运行越快，通常状况不需要调整 -+ 默认: 100ms ++ 默认：100ms ### `split-merge-interval` + 控制对同一个 Region 做 split 和 merge 操作的间隔，即对于新 split 的 Region 一段时间内不会被 merge。 -+ 默认: 1h ++ 默认：1h ### `max-snapshot-count` + 控制单个 store 最多同时接收或发送的 snapshot 数量，调度受制于这个配置来防止抢占正常业务的资源。 -+ 默认: 3 ++ 默认：3 ### `max-pending-peer-count` @@ -249,7 +249,7 @@ PD 配置文件比命令行参数支持更多的选项。你可以在 [conf/conf ### `tolerant-size-ratio` + 控制 balance 缓冲区大小。 -+ 默认值：0 (为 0 为自动调整缓冲区大小) ++ 默认值：0（为 0 为自动调整缓冲区大小） + 最小值：0 ### `enable-cross-table-merge` diff --git a/pd-control.md b/pd-control.md index 22cb2eaca9fe..218666b8f995 100644 --- a/pd-control.md +++ b/pd-control.md @@ -83,15 +83,15 @@ export PD_ADDR=http://127.0.0.1:2379 && ### `--detach` / `-d` -+ 使用单命令行模式(不进入 readline) -+ 默认值: true ++ 使用单命令行模式（不进入 readline） ++ 默认值：true ### `--help` / `-h` + 输出帮助信息 + 默认值：false -### `--interact` / `-i` +### `--interact`/`-i` + 使用交互模式（进入 readline） + 默认值：false @@ -99,18 +99,18 @@ export PD_ADDR=http://127.0.0.1:2379 && ### `--key` - 指定 PEM 格式的 SSL 证书密钥文件路径，即 `--cert` 所指定的证书的私钥 -- 默认值: "" +- 默认值："" -### `--pd` / `-u` +### `--pd`/`-u` + 指定 PD 的地址 + 默认地址：`http://127.0.0.1:2379` + 环境变量：`PD_ADDR` -### `--version` / `-V` +### `--version`/`-V` - 打印版本信息并退出 -- 默认值: false +- 默认值：false ## 命令 (command) diff --git a/post-installation-check.md b/post-installation-check.md index 3defbd8bffed..a481825fbe3d 100644 --- a/post-installation-check.md +++ b/post-installation-check.md @@ -56,7 +56,7 @@ tiup cluster display tidb-test mysql -u root -h ${tidb_server_host_IP_address} -P 4000 ``` -其中， `${tidb_server_host_IP_address}` 是在[初始化集群拓扑文件](/production-deployment-using-tiup.md#第-3-步初始化集群拓扑文件)时为 `tidb_servers` 配置的 IP 地址之一，例如 `10.0.1.7`。 +其中，`${tidb_server_host_IP_address}` 是在[初始化集群拓扑文件](/production-deployment-using-tiup.md#第-3-步初始化集群拓扑文件)时为 `tidb_servers` 配置的 IP 地址之一，例如 `10.0.1.7`。 输出下列信息表示登录成功： diff --git a/predicate-push-down.md b/predicate-push-down.md index 45d7b68030a4..05d7a939f413 100644 --- a/predicate-push-down.md +++ b/predicate-push-down.md @@ -86,7 +86,7 @@ desc select * from t where substring('123', a, 1) = '1'; 在该查询中，存在谓词 `substring('123', a, 1) = '1'`。 -从 explain 结果中可以看到，该谓词没有被下推到 TiKV 上进行计算，这是因为 TiKV coprocessor 中没有对 `substring` 内置函数进行支持, 因此无法将其下推到 TiKV 上。 +从 explain 结果中可以看到，该谓词没有被下推到 TiKV 上进行计算，这是因为 TiKV coprocessor 中没有对 `substring` 内置函数进行支持，因此无法将其下推到 TiKV 上。 ### 示例 5: 外连接中内表上的谓词不能下推 @@ -109,7 +109,7 @@ explain select * from t left join s on t.a = s.a where s.a is null; 在该查询中，内表 s 上存在谓词 `s.a is null`。 -从 explain 中可以看到，该谓词没有被下推到 join 前进行计算，这是因为外连接在不满足 on 条件时会对内表填充 NULL，而在该查询中 `s.a is null` 用来对 join 后的结果进行过滤，如果将其下推到 join 前在内表上进行过滤，则下推前后不等价, 因此不可进行下推。 +从 explain 中可以看到，该谓词没有被下推到 join 前进行计算，这是因为外连接在不满足 on 条件时会对内表填充 NULL，而在该查询中 `s.a is null` 用来对 join 后的结果进行过滤，如果将其下推到 join 前在内表上进行过滤，则下推前后不等价，因此不可进行下推。 ### 示例 6: 谓词中包含用户变量时不能下推 diff --git a/privilege-management.md b/privilege-management.md index 5ffc49dcb503..a314572c3953 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -492,7 +492,7 @@ User+Host 可能会匹配 `user` 表里面多行，为了处理这种情况，`u 连接成功之后，请求验证会检测执行操作是否拥有足够的权限。 -对于数据库相关请求 (`INSERT`，`UPDATE`)，先检查 `mysql.user` 表里面的用户全局权限，如果权限够，则直接可以访问。如果全局权限不足，则再检查 `mysql.db` 表。 +对于数据库相关请求 (`INSERT`, `UPDATE`)，先检查 `mysql.user` 表里面的用户全局权限，如果权限够，则直接可以访问。如果全局权限不足，则再检查 `mysql.db` 表。 `user` 表的权限是全局的，并且不管默认数据库是哪一个。比如 `user` 里面有 `DELETE` 权限，任何一行，任何的表，任何的数据库。 diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md index addb603e505c..33afd5d3be3e 100644 --- a/production-deployment-using-tiup.md +++ b/production-deployment-using-tiup.md @@ -81,9 +81,9 @@ aliases: ['/docs-cn/dev/production-offline-deployment-using-tiup/', '/zh/tidb/de #### 准备 TiUP 离线组件包 -方式一：在 [官方下载页面](https://pingcap.com/download-cn/) 选择对应版本的 TiDB server 离线镜像包（包含 TiUP 离线组件包）。 +方式一：在[官方下载页面](https://pingcap.com/download-cn/)选择对应版本的 TiDB server 离线镜像包（包含 TiUP 离线组件包）。 -方式二：使用 `tiup mirror clone` 命令手动打包离线组件包，步骤如下： +方式二：使用 `tiup mirror clone` 命令手动打包离线组件包。步骤如下： 1. 在线环境中安装 TiUP 包管理器工具 @@ -232,7 +232,7 @@ alertmanager_servers: > > - 配置的层次结构使用 `.` 表示。如：`log.slow-threshold`。更多格式参考 [TiUP 配置参数模版](https://github.com/pingcap/tiup/blob/master/embed/templates/examples/topology.example.yaml)。 > -> - 更多参数说明，请参考 [TiDB `config.toml.example`](https://github.com/pingcap/tidb/blob/master/config/config.toml.example)、[TiKV `config.toml.example`](https://github.com/tikv/tikv/blob/master/etc/config-template.toml) 、 [PD `config.toml.example`](https://github.com/pingcap/pd/blob/master/conf/config.toml) 和 [TiFlash 配置参数](/tiflash/tiflash-configuration.md)。 +> - 更多参数说明，请参考 [TiDB `config.toml.example`](https://github.com/pingcap/tidb/blob/master/config/config.toml.example)、[TiKV `config.toml.example`](https://github.com/tikv/tikv/blob/master/etc/config-template.toml)、[PD `config.toml.example`](https://github.com/pingcap/pd/blob/master/conf/config.toml) 和 [TiFlash 配置参数](/tiflash/tiflash-configuration.md)。 ## 第 4 步：执行部署命令 diff --git a/quick-start-with-tidb.md b/quick-start-with-tidb.md index 83fb8e540f2a..1f65173ac7f2 100644 --- a/quick-start-with-tidb.md +++ b/quick-start-with-tidb.md @@ -252,7 +252,7 @@ TiDB 是一个分布式系统。最基础的 TiDB 测试集群通常由 2 个 Ti - 部署需要使用部署主机的 root 用户及密码 - 部署主机[关闭防火墙](/check-before-deployment.md#检测及关闭目标部署机器的防火墙)或者开放 TiDB 集群的节点间所需端口 -- 目前 TiUP 支持在 x86_64 (AMD64 和 ARM) 架构上部署 TiDB 集群 +- 目前 TiUP 支持在 x86_64（AMD64 和 ARM）架构上部署 TiDB 集群 - 在 AMD64 架构下，建议使用 CentOS 7.3 及以上版本 Linux 操作系统 - 在 ARM 架构下，建议使用 CentOS 7.6 1810 版本 Linux 操作系统 diff --git a/read-historical-data.md b/read-historical-data.md index 031aff360ab6..b2f721112099 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -21,11 +21,11 @@ TiDB 实现了通过标准 SQL 接口读取历史数据功能，无需特殊的 ## 操作流程 -为支持读取历史版本数据， TiDB 引入了一个新的系统变量 [`tidb_snapshot`](/system-variables.md#tidb_snapshot)： +为支持读取历史版本数据，TiDB 引入了一个新的系统变量 [`tidb_snapshot`](/system-variables.md#tidb_snapshot)： - 这个变量的作用域为 `SESSION`。 - 你可以通过标准的 `SET` 语句修改这个变量的值。 -- 这个变量的数据类型为文本类型，能够存储 TSO 和日期时间。TSO 是从 PD 端获取的全局授时的时间戳，日期时间的格式为：“2016-10-08 16:45:26.999”，一般来说可以只写到秒，比如”2016-10-08 16:45:26”。 +- 这个变量的数据类型为文本类型，能够存储 TSO 和日期时间。TSO 是从 PD 端获取的全局授时的时间戳，日期时间的格式为："2016-10-08 16:45:26.999"，一般来说可以只写到秒，比如”2016-10-08 16:45:26”。 - 当这个变量被设置时，TiDB 会按照设置的时间戳建立 Snapshot（没有开销，只是创建数据结构），随后所有的 `SELECT` 操作都会从这个 Snapshot 上读取数据。 > **注意：** diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index d032de17615a..e68c98b4dd80 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -362,7 +362,7 @@ tiup cluster display 1. 使用 pd-ctl 的 store 命令在 PD 中查看该 TiFlash 节点对应的 store id。 - * 在 [pd-ctl](/pd-control.md) (tidb-ansible 目录下的 `resources/bin` 包含对应的二进制文件) 中输入 store 命令。 + * 在 [pd-ctl](/pd-control.md)（tidb-ansible 目录下的 `resources/bin` 包含对应的二进制文件）中输入 store 命令。 * 若使用 TiUP 部署，可以调用以下命令代替 `pd-ctl`： @@ -374,7 +374,7 @@ tiup cluster display > **注意：** > - > 如果集群中有多个 PD 实例，只需在以上命令中指定一个活跃 PD 实例的 IP:端口即可。 + > 如果集群中有多个 PD 实例，只需在以上命令中指定一个活跃 PD 实例的 `IP:端口`即可。 2. 在 pd-ctl 中下线该 TiFlash 节点。 @@ -390,7 +390,7 @@ tiup cluster display > **注意：** > - > 如果集群中有多个 PD 实例，只需在以上命令中指定一个活跃 PD 实例的 IP:端口即可。 + > 如果集群中有多个 PD 实例，只需在以上命令中指定一个活跃 PD 实例的 `IP:端口`即可。 3. 等待该 TiFlash 节点对应的 store 消失或者 state_name 变成 Tombstone 再关闭 TiFlash 进程。 diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index 1e470e1cce3f..0fa8a7c39635 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -13,9 +13,9 @@ aliases: ['/docs-cn/dev/schedule-replicas-by-topology-labels/','/docs-cn/dev/how ### 设置 TiKV 的 `labels` 配置 -TiKV 支持在命令行参数或者配置文件中以键值对的形式绑定一些属性，我们把这些属性叫做标签（label）。TiKV 在启动后，会将自身的标签上报给 PD，因此我们可以使用标签来标识 TiKV 节点的地理位置。 +TiKV 支持在命令行参数或者配置文件中以键值对的形式绑定一些属性，我们把这些属性叫做标签 (label)。TiKV 在启动后，会将自身的标签上报给 PD，因此我们可以使用标签来标识 TiKV 节点的地理位置。 -比如集群的拓扑结构分成三层：机房（zone) -> 机架（rack）-> 主机（host），就可以使用这 3 个标签来设置 TiKV 的位置。 +比如集群的拓扑结构分成三层：机房 (zone) -> 机架 (rack) -> 主机 (host)，就可以使用这 3 个标签来设置 TiKV 的位置。 使用命令行参数的方式： @@ -63,7 +63,7 @@ pd-ctl config set location-labels zone,rack,host ### 设置 PD 的 `isolation-level` 配置 -在配置了 `location-labels` 的前提下，用户可以还通过 `isolation-level` 配置来进一步加强对 TiKV 集群的拓扑隔离要求。假设按照上面的说明通过 `location-labels` 将集群的拓扑结构分成三层：机房（zone) -> 机架（rack）-> 主机（host），并对 `isolation-level` 作如下配置： +在配置了 `location-labels` 的前提下，用户可以还通过 `isolation-level` 配置来进一步加强对 TiKV 集群的拓扑隔离要求。假设按照上面的说明通过 `location-labels` 将集群的拓扑结构分成三层：机房 (zone) -> 机架 (rack) -> 主机 (host)，并对 `isolation-level` 作如下配置 {{< copyable "" >}} @@ -151,9 +151,9 @@ PD 在副本调度时，会按照 label 层级，保证同一份数据的不同 下面以上一节的拓扑结构为例分析。 -假设集群副本数设置为 3（`max-replicas=3`），因为总共有 3 个 zone，PD 会保证每个 Region 的 3 个副本分别放置在 z1/z2/z3，这样当任何一个数据中心发生故障时，TiDB 集群依然是可用的。 +假设集群副本数设置为 3 (`max-replicas=3`)，因为总共有 3 个 zone，PD 会保证每个 Region 的 3 个副本分别放置在 z1/z2/z3，这样当任何一个数据中心发生故障时，TiDB 集群依然是可用的。 -假如集群副本数设置为 5（`max-replicas=5`），因为总共只有 3 个 zone，在这一层级 PD 无法保证各个副本的隔离，此时 PD 调度器会退而求其次，保证在 host 这一层的隔离。也就是说，会出现一个 Region 的多个副本分布在同一个 zone 的情况，但是不会出现多个副本分布在同一台主机。 +假如集群副本数设置为 5 (`max-replicas=5`)，因为总共只有 3 个 zone，在这一层级 PD 无法保证各个副本的隔离，此时 PD 调度器会退而求其次，保证在 host 这一层的隔离。也就是说，会出现一个 Region 的多个副本分布在同一个 zone 的情况，但是不会出现多个副本分布在同一台主机。 在 5 副本配置的前提下，如果 z3 出现了整体故障或隔离，并且 z3 在一段时间后仍然不能恢复（由 `max-store-down-time` 控制），PD 会通过调度补齐 5 副本，此时可用的主机只有 3 个了，故而无法保证 host 级别的隔离，于是可能出现多个副本被调度到同一台主机的情况。 diff --git a/schema-object-names.md b/schema-object-names.md index e1e0faebb5b8..44d828bffc83 100644 --- a/schema-object-names.md +++ b/schema-object-names.md @@ -62,7 +62,7 @@ SELECT 1 AS `identifier`, 2 AS 'string'; ## Identifier Qualifiers -Object Names (对象名字) 有时可以被限定或者省略。例如在创建表的时候可以省略数据库限定名： +Object Names（对象名字）有时可以被限定或者省略。例如在创建表的时候可以省略数据库限定名： {{< copyable "sql" >}} diff --git a/shard-row-id-bits.md b/shard-row-id-bits.md index c81bbc97f8d0..ff78f2252f87 100644 --- a/shard-row-id-bits.md +++ b/shard-row-id-bits.md @@ -20,5 +20,5 @@ aliases: ['/docs-cn/dev/shard-row-id-bits/'] ## 语句示例 -- `CREATE TABLE`：`CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4;` -- `ALTER TABLE`：`ALTER TABLE t SHARD_ROW_ID_BITS = 4;` +- `CREATE TABLE`: `CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4;` +- `ALTER TABLE`: `ALTER TABLE t SHARD_ROW_ID_BITS = 4;` diff --git a/sql-mode.md b/sql-mode.md index 09574ad8b363..13da05ef2983 100644 --- a/sql-mode.md +++ b/sql-mode.md @@ -5,16 +5,16 @@ aliases: ['/docs-cn/dev/sql-mode/','/docs-cn/dev/reference/sql/sql-mode/'] # SQL 模式 -TiDB 服务器采用不同 SQL 模式来操作，且不同客户端可以应用不同模式。SQL 模式定义 TiDB 支持哪些 SQL 语法及执行哪种数据验证检查. +TiDB 服务器采用不同 SQL 模式来操作，且不同客户端可以应用不同模式。SQL 模式定义 TiDB 支持哪些 SQL 语法及执行哪种数据验证检查。 -TiDB 启动之后采用 `SET [ SESSION | GLOBAL ] sql_mode='modes'`设置 SQL 模式。设置 GLOBAL 级别的 SQL 模式时用户需要有 SUPER 权限，并且只会影响到从设置 SQL 模式开始后续新建立的连接（注：老连接不受影响)。 SESSION 级别的 SQL 模式的变化只会影响当前的客户端。 +TiDB 启动之后采用 `SET [ SESSION | GLOBAL ] sql_mode='modes'`设置 SQL 模式。设置 GLOBAL 级别的 SQL 模式时用户需要有 SUPER 权限，并且只会影响到从设置 SQL 模式开始后续新建立的连接（注：老连接不受影响）。 SESSION 级别的 SQL 模式的变化只会影响当前的客户端。 Modes 是用逗号 (',') 间隔开的一系列不同的模式。使用 `SELECT @@sql_mode` 语句查询当前 SQL 模式，SQL 模式默认值：`ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION`。 ## 重要的 sql_mode 值 * ANSI: 符合标准 SQL ，对数据进行校验，如果不符合定义类型或长度，对数据类型调整或截断保存，且返回warning警告。 -* STRICT_TRANS_TABLES: 严格模式，对数据进行严格校验，当数据出现错误时，插入到表中，并且返回错误。 +* STRICT_TRANS_TABLES: 严格模式，对数据进行严格校验，当数据出现错误时，插入到表中，并且返回错误。 * TRADITIONAL: 采用此模式使 TiDB 的行为象 "传统" SQL 数据库系统，当在列中插入不正确的值时“给出错误而不是警告”，一旦发现错误立即放弃INSERT/UPDATE。 ## SQL mode 列表，如下 diff --git a/sql-physical-optimization.md b/sql-physical-optimization.md index c20309fd2c07..f3f6ce2274cb 100644 --- a/sql-physical-optimization.md +++ b/sql-physical-optimization.md @@ -7,7 +7,7 @@ aliases: ['/docs-cn/dev/sql-physical-optimization/'] 物理优化是基于代价的优化，为上一阶段产生的逻辑执行计划制定物理执行计划。这一阶段中，优化器会为逻辑执行计划中的每个算子选择具体的物理实现。逻辑算子的不同物理实现有着不同的时间复杂度、资源消耗和物理属性等。在这个过程中，优化器会根据数据的统计信息来确定不同物理实现的代价，并选择整体代价最小的物理执行计划。 -[理解 TiDB 执行计划](/explain-overview.md) 文档已对每个物理算子进行了一些介绍。在本章我们会重点介绍以下方面： +[理解 TiDB 执行计划](/explain-overview.md)文档已对每个物理算子进行了一些介绍。在本章我们会重点介绍以下方面： - 在[索引的选择](/choose-index.md)中会介绍 TiDB 在一张表有多个索引时，如何选择最优的索引进行表的访问。 - 在[统计信息简介](/statistics.md)中会介绍 TiDB 收集了哪些统计信息来获得表的数据分布情况 diff --git a/sql-plan-management.md b/sql-plan-management.md index 09e9c6f6a3d1..9759e4673c92 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -19,7 +19,7 @@ aliases: ['/docs-cn/dev/sql-plan-management/','/docs-cn/dev/reference/performanc CREATE [GLOBAL | SESSION] BINDING FOR BindableStmt USING BindableStmt; ``` -该语句可以在 GLOBAL 或者 SESSION 作用域内为 SQL 绑定执行计划。目前支持的可创建执行计划绑定的 SQL 类型（BindableStmt）包括：`SELECT`，`DELETE`，`UPDATE` 和带有 `SELECT` 子查询的 `INSERT` / `REPLACE`。 +该语句可以在 GLOBAL 或者 SESSION 作用域内为 SQL 绑定执行计划。目前支持的可创建执行计划绑定的 SQL 类型 (BindableStmt) 包括：`SELECT`，`DELETE`，`UPDATE` 和带有 `SELECT` 子查询的 `INSERT`/`REPLACE`。 其中，有两类特定的语法由于语法冲突不能创建执行计划绑定，例如： @@ -61,7 +61,7 @@ using > **注意：** > -> 在对带 `SELECT` 子查询的 `INSERT` / `REPLACE` 语句创建执行计划绑定时，需要将想要绑定的优化器 Hints 指定在 `SELECT` 子查询中，而不是 `INSERT` / `REPLACE` 关键字后，不然优化器 Hints 不会生效。 +> 在对带 `SELECT` 子查询的 `INSERT`/`REPLACE` 语句创建执行计划绑定时，需要将想要绑定的优化器 Hints 指定在 `SELECT` 子查询中，而不是 `INSERT`/`REPLACE` 关键字后，不然优化器 Hints 不会生效。 例如： @@ -139,7 +139,7 @@ CREATE BINDING FOR SELECT * FROM t WHERE a > 1 USING SELECT * FROM t use index(i > **注意：** > -> 对于 `PREPARE` / `EXECUTE` 语句组，或者用二进制协议执行的查询，创建执行计划绑定的对象应当是查询语句本身，而不是 `PREPARE` / `EXECUTE` 语句。 +> 对于 `PREPARE`/`EXECUTE` 语句组，或者用二进制协议执行的查询，创建执行计划绑定的对象应当是查询语句本身，而不是 `PREPARE`/`EXECUTE` 语句。 ### 删除绑定 @@ -203,7 +203,7 @@ SHOW [GLOBAL | SESSION] BINDINGS [ShowLikeOrWhere]; - TiDB 内部执行的 SQL 语句，比如统计信息自动加载使用的 SELECT 查询； - 存在手动创建的执行计划绑定的 SQL 语句； -对于 `PREPARE` / `EXECUTE` 语句组，或通过二进制协议执行的查询，TiDB 会为真正的查询（而不是 `PREPARE` / `EXECUTE` 语句）自动捕获绑定。 +对于 `PREPARE`/`EXECUTE` 语句组，或通过二进制协议执行的查询，TiDB 会为真正的查询（而不是 `PREPARE`/`EXECUTE` 语句）自动捕获绑定。 > **注意：** > diff --git a/system-variables.md b/system-variables.md index d093a0f371e7..b9bb6689af66 100644 --- a/system-variables.md +++ b/system-variables.md @@ -693,7 +693,7 @@ MPP 是 TiFlash 引擎提供的分布式计算框架，允许节点之间的数 - `index lookup` - `index lookup join` - `hash join` -- `hash aggregation` (partial 和 final 阶段) +- `hash aggregation`（partial 和 final 阶段） - `window` - `projection` @@ -995,7 +995,7 @@ v5.0 后，用户仍可以单独修改以上系统变量（会有废弃警告） - 默认值：`OFF` - 这个变量用来设置优化器是否执行带有 `Distinct` 的聚合函数（比如 `select count(distinct a) from t`）下推到 Coprocessor 的优化操作。当查询中带有 `Distinct` 的聚合操作执行很慢时，可以尝试设置该变量为 `1`。 -在以下示例中，`tidb_opt_distinct_agg_push_down` 开启前，TiDB 需要从 TiKV 读取所有数据，并在 TiDB 侧执行 `distinct`。`tidb_opt_distinct_agg_push_down` 开启后， `distinct a` 被下推到了 Coprocessor，在 `HashAgg_5` 里新增里一个 `group by` 列 `test.t.a`。 +在以下示例中，`tidb_opt_distinct_agg_push_down` 开启前，TiDB 需要从 TiKV 读取所有数据，并在 TiDB 侧执行 `distinct`。`tidb_opt_distinct_agg_push_down` 开启后，`distinct a` 被下推到了 Coprocessor，在 `HashAgg_5` 里新增里一个 `group by` 列 `test.t.a`。 ```sql mysql> desc select count(distinct a) from test.t; diff --git a/table-filter.md b/table-filter.md index 0252ca4206f8..ddddb6f08405 100644 --- a/table-filter.md +++ b/table-filter.md @@ -106,9 +106,9 @@ data.* 此处，“字符”指的是一个 Unicode 码位，例如： -* `U+00E9` (é) 是 1 个字符。 -* `U+0065 U+0301` (é) 是 2 个字符。 -* `U+1F926 U+1F3FF U+200D U+2640 U+FE0F` (🤦🏿‍♀️) 是 5 个字符。 +* `U+00E9` "é" 是 1 个字符。 +* `U+0065，U+0301` "é" 是 2 个字符。 +* `U+1F926 U+1F3FF U+200D U+2640 U+FE0F` "🤦🏿‍♀️" 是 5 个字符。 ### 使用文件导入 diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md index 6ab7d57aad9f..e9693d15538a 100644 --- a/three-data-centers-in-two-cities-deployment.md +++ b/three-data-centers-in-two-cities-deployment.md @@ -49,7 +49,7 @@ TiDB 分布式数据库通过 Raft 算法原生支持两地三中心架构的建 ![两地三中心配置详图](/media/three-data-centers-in-two-cities-deployment-02.png) - 如上图所示，北京有两个机房 IDC1 和 IDC2，机房 IDC1 中有三套机架 RAC1、RAC2、RAC3，机房 IDC2 有机架 RAC4、RAC5；西安机房 IDC3 有机架 RAC6。 -- 如上图中 RAC1 机架所示，TiDB、PD 服务部署在同一台服务器上，还有两台 TiKV 服务器；每台 TiKV 服务器部署 2 个 TiKV 实例（tikv-server），RAC2、RAC4、RAC5、RAC6 类似。 +- 如上图中 RAC1 机架所示，TiDB、PD 服务部署在同一台服务器上，还有两台 TiKV 服务器；每台 TiKV 服务器部署 2 个 TiKV 实例 (tikv-server)，RAC2、RAC4、RAC5、RAC6 类似。 - 机架 RAC3 上安放 TiDB Server 及中控 + 监控服务器。部署 TiDB Server，用于日常管理维护、备份使用。中控 + 监控服务器上部署 Prometheus、Grafana 以及恢复工具； - 另可增加备份服务器，其上部署 Drainer，Drainer 以输出 file 文件的方式将 binlog 数据保存到指定位置，实现增量备份的目的。 diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index a8c16a33f32a..3d1ce2887706 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -49,7 +49,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ + 单位：Byte + 当单条 SQL 语句使用临时磁盘，导致 TiDB server 的总体临时磁盘总量超过 `tmp-storage-quota` 时，当前 SQL 操作会被取消，并返回 `Out Of Global Storage Quota!` 错误。 + 当 `tmp-storage-quota` 小于 0 时则没有上述检查与限制。 -+ 默认值: -1 ++ 默认值：-1 + 当 `tmp-storage-path` 的剩余可用容量低于 `tmp-storage-quota` 所定义的值时，TiDB server 启动时将会报出错误并退出。 ### `oom-action` @@ -103,7 +103,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `server-version` -+ 用来修改 TiDB 在以下情况下返回的版本号: ++ 用来修改 TiDB 在以下情况下返回的版本号： - 当使用内置函数 `VERSION()` 时。 - 当与客户端初始连接，TiDB 返回带有服务端版本号的初始握手包时。具体可以查看 MySQL 初始握手包的[描述](https://dev.mysql.com/doc/internals/en/connection-phase-packets.html#packet-Protocol::Handshake)。 + 默认值："" @@ -117,7 +117,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `repair-table-list` -+ 配合 `repair-mode` 为 true 时使用，用于列出实例中需要修复的坏表的名单，该名单的写法为 ["db.table1","db.table2"...]。 ++ 配合 `repair-mode` 为 true 时使用，用于列出实例中需要修复的坏表的名单，该名单的写法为 ["db.table1","db.table2", ……]。 + 默认值：[] + 默认情况下，该 list 名单为空，表示没有所需修复的坏表信息。 @@ -182,7 +182,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `level` -+ 指定日志的输出级别, 可选项为 [debug, info, warn, error, fatal] ++ 指定日志的输出级别，可选项为 [debug, info, warn, error, fatal] + 默认值："info" ### `format` @@ -209,7 +209,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `slow-query-file` + 慢查询日志的文件名。 -+ 默认值："tidb-slow.log"，注：由于 TiDB V2.1.8 更新了慢日志格式，所以将慢日志单独输出到了慢日志文件。V2.1.8 之前的版本，该变量的默认值是 ""。 ++ 默认值："tidb-slow.log"。注：由于 TiDB V2.1.8 更新了慢日志格式，所以将慢日志单独输出到了慢日志文件。V2.1.8 之前的版本，该变量的默认值是 ""。 + 设置后，慢查询日志会单独输出到该文件。 ### `slow-threshold` @@ -312,8 +312,8 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `spilled-file-encryption-method` + 内存落盘文件的加密方式。 -+ 默认值: `"plaintext"`，表示不进行加密 -+ 可选值：`"plaintext"`、`"aes128-ctr"` ++ 默认值：`"plaintext"`，表示不进行加密。 ++ 可选值：`"plaintext"`、`"aes128-ctr"`。 ## performance @@ -452,7 +452,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/ ### `enforce-mpp` -+ 用于控制是否忽略优化器代价估算，强制使用 TiFlash 的 MPP 模式执行查询. ++ 用于控制是否忽略优化器代价估算，强制使用 TiFlash 的 MPP 模式执行查询。 + 默认值：false + 该配置项可以控制系统变量 [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-从-v51-版本开始引入) 的初始值。例如，当设置该配置项为 true 时，`tidb_enforce_mpp` 的默认值为 ON。 diff --git a/tidb-control.md b/tidb-control.md index 4b200ceee52a..7d5c3d115b2b 100644 --- a/tidb-control.md +++ b/tidb-control.md @@ -17,7 +17,7 @@ TiDB Control 是 TiDB 的命令行工具，用于获取 TiDB 状态信息，多 ### 通过 TiUP 安装 -在安装 TiUP 之后， 可以使用 `tiup ctl tidb` 命令来获取 TiDB Control 的二进制程序以及运行 TiDB Control。 +在安装 TiUP 之后，可以使用 `tiup ctl tidb` 命令来获取 TiDB Control 的二进制程序以及运行 TiDB Control。 ### 从源代码编译安装 @@ -70,7 +70,7 @@ TiDB Control 是 TiDB 的命令行工具，用于获取 TiDB 状态信息，多 - `--ssl-key` 连接使用的 TLS 密钥文件路径 - `--ssl-cert` 连接使用的 TLS 证书文件路径 -其中 `--pdhost` 和 `--pdport` 主要是用于 `etcd` 子命令，例如：`tidb-ctl etcd ddlinfo`。如不添加地址和端口将使用默认值，TiDB/PD 服务默认的地址是 127.0.0.1 (服务地址只能使用 IP 地址)，TiDB 服务端口默认的端口是 10080，PD 服务端口默认的端口是 2379 **连接选项是全局选项，适用于以下所有命令。** +其中 `--pdhost` 和 `--pdport` 主要是用于 `etcd` 子命令，例如：`tidb-ctl etcd ddlinfo`。如不添加地址和端口将使用默认值，TiDB/PD 服务默认的地址是 127.0.0.1（服务地址只能使用 IP 地址），TiDB 服务端口默认的端口是 10080，PD 服务端口默认的端口是 2379 **连接选项是全局选项，适用于以下所有命令。** ### schema 命令 @@ -80,7 +80,7 @@ in 子命令用来通过数据库名获取数据库中所有表的表结构。 `tidb-ctl schema in {数据库名}` -如：`tidb-ctl schema in mysql` 将得到以下结果： +如：`tidb-ctl schema in mysql` 将得到以下结果 ```json [ @@ -102,7 +102,7 @@ in 子命令用来通过数据库名获取数据库中所有表的表结构。 如希望指定表名，可以使用 `tidb-ctl schema in {数据库名} -n {表名}` 进行过滤。 -如：`tidb-ctl schema in mysql -n db` 将得到 mysql 库中 db 表的表结构，结果如下： +如：`tidb-ctl schema in mysql -n db` 将得到 mysql 库中 db 表的表结构。结果如下： ```json { @@ -286,7 +286,7 @@ tidb-ctl base64decode [table_id] [base64_data] ### etcd 命令 * `tidb-ctl etcd ddlinfo` 获取 DDL 信息。 -* `tidb-ctl etcd putkey KEY VALUE` 添加 KEY VALUE 到 etcd (所有的 KEY 会添加到 `/tidb/ddl/all_schema_versions/` 之下)。 +* `tidb-ctl etcd putkey KEY VALUE` 添加 KEY VALUE 到 etcd（所有的 KEY 会添加到 `/tidb/ddl/all_schema_versions/` 之下）。 {{< copyable "shell-regular" >}} diff --git a/tidb-scheduling.md b/tidb-scheduling.md index 17a07b856ee9..7e135c630da7 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -33,13 +33,13 @@ TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为 对以上的问题和场景进行分类和整理，可归为以下两类： -**第一类：作为一个分布式高可用存储系统，必须满足的需求，包括几种：** +**第一类：作为一个分布式高可用存储系统，必须满足的需求，包括几种** * 副本数量不能多也不能少 * 副本需要根据拓扑结构分布在不同属性的机器上 * 节点宕机或异常能够自动合理快速地进行容灾 -**第二类：作为一个良好的分布式系统，需要考虑的地方包括：** +**第二类：作为一个良好的分布式系统，需要考虑的地方包括** * 维持整个集群的 Leader 分布均匀 * 维持每个节点的储存容量均匀 @@ -67,7 +67,7 @@ TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为 **每个 TiKV 节点会定期向 PD 汇报节点的状态信息** -TiKV 节点（Store）与 PD 之间存在心跳包，一方面 PD 通过心跳包检测每个 Store 是否存活，以及是否有新加入的 Store；另一方面，心跳包中也会携带这个 [Store 的状态信息](https://github.com/pingcap/kvproto/blob/master/proto/pdpb.proto#L473)，主要包括： +TiKV 节点 (Store) 与 PD 之间存在心跳包，一方面 PD 通过心跳包检测每个 Store 是否存活，以及是否有新加入的 Store；另一方面，心跳包中也会携带这个 [Store 的状态信息](https://github.com/pingcap/kvproto/blob/master/proto/pdpb.proto#L473)，主要包括： * 总磁盘容量 * 可用磁盘容量 @@ -79,7 +79,7 @@ TiKV 节点（Store）与 PD 之间存在心跳包，一方面 PD 通过心跳 **每个 Raft Group 的 Leader 会定期向 PD 汇报 Region 的状态信息** -每个 Raft Group 的 Leader 和 PD 之间存在心跳包，用于汇报这个[Region 的状态](https://github.com/pingcap/kvproto/blob/master/proto/pdpb.proto#L312)，主要包括下面几点信息： +每个 Raft Group 的 Leader 和 PD 之间存在心跳包，用于汇报这个 [Region 的状态](https://github.com/pingcap/kvproto/blob/master/proto/pdpb.proto#L312)，主要包括下面几点信息： * Leader 的位置 * Followers 的位置 diff --git a/tidb-storage.md b/tidb-storage.md index 7aa5506810aa..329f5525e318 100644 --- a/tidb-storage.md +++ b/tidb-storage.md @@ -61,7 +61,7 @@ TiKV 选择了第二种方式，将整个 Key-Value 空间分成很多段，每 这两点非常重要： -* 先看第一点，数据按照 Key 切分成很多 Region，每个 Region 的数据只会保存在一个节点上面（暂不考虑多副本）。TiDB 系统会有一个组件（PD）来负责将 Region 尽可能均匀的散布在集群中所有的节点上，这样一方面实现了存储容量的水平扩展（增加新的节点后，会自动将其他节点上的 Region 调度过来），另一方面也实现了负载均衡（不会出现某个节点有很多数据，其他节点上没什么数据的情况）。同时为了保证上层客户端能够访问所需要的数据，系统中也会有一个组件（PD）记录 Region 在节点上面的分布情况，也就是通过任意一个 Key 就能查询到这个 Key 在哪个 Region 中，以及这个 Region 目前在哪个节点上（即 Key 的位置路由信息）。至于负责这两项重要工作的组件（PD），会在后续介绍。 +* 先看第一点，数据按照 Key 切分成很多 Region，每个 Region 的数据只会保存在一个节点上面（暂不考虑多副本）。TiDB 系统会有一个组件 (PD) 来负责将 Region 尽可能均匀的散布在集群中所有的节点上，这样一方面实现了存储容量的水平扩展（增加新的节点后，会自动将其他节点上的 Region 调度过来），另一方面也实现了负载均衡（不会出现某个节点有很多数据，其他节点上没什么数据的情况）。同时为了保证上层客户端能够访问所需要的数据，系统中也会有一个组件 (PD) 记录 Region 在节点上面的分布情况，也就是通过任意一个 Key 就能查询到这个 Key 在哪个 Region 中，以及这个 Region 目前在哪个节点上（即 Key 的位置路由信息）。至于负责这两项重要工作的组件 (PD)，会在后续介绍。 * 对于第二点，TiKV 是以 Region 为单位做数据的复制，也就是一个 Region 的数据会保存多个副本，TiKV 将每一个副本叫做一个 Replica。Replica 之间是通过 Raft 来保持数据的一致，一个 Region 的多个 Replica 会保存在不同的节点上，构成一个 Raft Group。其中一个 Replica 会作为这个 Group 的 Leader，其他的 Replica 作为 Follower。默认情况下，所有的读和写都是通过 Leader 进行，读操作在 Leader 上即可完成，而写操作再由 Leader 复制给 Follower。 大家理解了 Region 之后，应该可以理解下面这张图： @@ -98,8 +98,8 @@ KeyN_Version1 -> Value …… ``` -注意，对于同一个 Key 的多个版本，版本号较大的会被放在前面，版本号小的会被放在后面（见 [Key-Value](#key-value-pairs键值对) 一节, Key 是有序的排列），这样当用户通过一个 Key + Version 来获取 Value 的时候，可以通过 Key 和 Version 构造出 MVCC 的 Key，也就是 Key_Version。然后可以直接通过 RocksDB 的 SeekPrefix(Key_Version) API，定位到第一个大于等于这个 Key_Version 的位置。 +注意，对于同一个 Key 的多个版本，版本号较大的会被放在前面，版本号小的会被放在后面（见 [Key-Value](#key-value-pairs键值对) 一节，Key 是有序的排列），这样当用户通过一个 Key + Version 来获取 Value 的时候，可以通过 Key 和 Version 构造出 MVCC 的 Key，也就是 Key_Version。然后可以直接通过 RocksDB 的 SeekPrefix(Key_Version) API，定位到第一个大于等于这个 Key_Version 的位置。 ## 分布式 ACID 事务 -TiKV 的事务采用的是 Google 在 BigTable 中使用的事务模型： [Percolator](https://research.google.com/pubs/pub36726.html) ，TiKV 根据这篇论文实现，并做了大量的优化。详细介绍参见[事务概览](/transaction-overview.md)。 +TiKV 的事务采用的是 Google 在 BigTable 中使用的事务模型：[Percolator](https://research.google.com/pubs/pub36726.html) ，TiKV 根据这篇论文实现，并做了大量的优化。详细介绍参见[事务概览](/transaction-overview.md)。 diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index e29afdc473a2..b8712355f2f3 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -16,7 +16,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - 1.1.2 多台 TiKV 同时内存不足 (OOM)，导致 Region 在一定时期内没有 Leader，见案例 [case-991](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case991.md)。 -- 1.1.3 TiKV 报 `TiKV server is busy` 错误，超过 `backoff` 时间，参考[4.3 客户端报 `server is busy` 错误](#43-客户端报-server-is-busy-错误)。`TiKV server is busy` 属于内部流控机制，后续可能不计入 `backoff` 时间。 +- 1.1.3 TiKV 报 `TiKV server is busy` 错误，超过 `backoff` 时间，参考 [4.3 客户端报 `server is busy` 错误](#43-客户端报-server-is-busy-错误)。`TiKV server is busy` 属于内部流控机制，后续可能不计入 `backoff` 时间。 - 1.1.4 多台 TiKV 启动不了，导致 Region 没有 Leader。单台物理主机部署多个 TiKV 实例，一个物理机挂掉，由于 label 配置错误导致 Region 没有 Leader，见案例 [case-228](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case228.md)。 @@ -31,7 +31,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles ### 2.1 延迟短暂升高 - 2.1.1 TiDB 执行计划不对导致延迟升高，请参考 [3.3 执行计划不对](#33-执行计划不对)。 -- 2.1.2 PD 出现选举问题或者 OOM 问题，请参考 [5.2 PD 选举问题](#52-pd-选举问题) 和 [5.3 PD OOM 问题](#53-pd-oom)。 +- 2.1.2 PD 出现选举问题或者 OOM 问题，请参考 [5.2 PD 选举问题](#52-pd-选举问题)和 [5.3 PD OOM 问题](#53-pd-oom)。 - 2.1.3 某些 TiKV 大量掉 Leader，请参考 [4.4 某些 TiKV 大量掉 Leader](#44-某些-tikv-大量掉-leader)。 ### 2.2 Latency 持续升高 @@ -56,7 +56,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - 3.1.2 TiDB DDL job 卡住不动/执行很慢（通过 `admin show ddl jobs` 可以查看 DDL 进度）： - - 原因 1：与外部组件（PD/TiKV）的网络问题。 + - 原因 1：与外部组件 (PD/TiKV) 的网络问题。 - 原因 2：早期版本（v3.0.8 之前）TiDB 内部自身负载很重（高并发下可能产生了很多协程）。 @@ -88,7 +88,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - 原因 1：执行 DML 的 TiDB 被 `graceful kill` 后准备退出，且此 DML 对应的事务执行时间超过一个 DDL lease，在事务提交的时候会报此错。 - - 原因 2：TiDB 在执行 DML 时，有一段时间连不上 PD 和 TiKV，导致以下问题： + - 原因 2：TiDB 在执行 DML 时，有一段时间连不上 PD 和 TiKV，导致以下问题 - TiDB 在超过一个 DDL Lease（默认 `45s`）的时间内没有加载到新的 schema；或者 - TiDB 断开与 PD 之间带 `keep alive` 设置的连接。 @@ -117,8 +117,8 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - 3.2.2 定位造成 OOM 的 SQL（目前所有版本都无法完成精准定位，需要在发现 SQL 后再做进一步分析，确认 OOM 是否的确由该 SQL 造成）： - - `> = v3.0.0` 的版本, 可以在 tidb.log 中 `grep "expensive_query"`，该 log 会记录运行超时、或使用内存超过阈值的 SQL。 - - `< v3.0.0` 的版本, 通过 `grep "memory exceeds quota"` 定位运行时内存超限的 SQL。 + - `> = v3.0.0` 的版本，可以在 tidb.log 中 `grep "expensive_query"`，该 log 会记录运行超时、或使用内存超过阈值的 SQL。 + - `< v3.0.0` 的版本，通过 `grep "memory exceeds quota"` 定位运行时内存超限的 SQL。 > **注意：** > @@ -148,9 +148,9 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - 3.3.2 排查执行计划问题 - - `explain analyze {SQL}`。在执行时间可以接受的情况下，对比 `explain analyze` 结果中 `count` 和 execution info 中 `rows` 的数目差距。如果在 `TableScan`/`IndexScan` 行上发现比较大的差距，很大可能是统计信息出问题；如果在其他行上发现较大差距，则也有可能是非统计信息问题。 + - `explain analyze {SQL}` 在执行时间可以接受的情况下，对比 `explain analyze` 结果中 `count` 和 execution info 中 `rows` 的数目差距。如果在 `TableScan`/`IndexScan` 行上发现比较大的差距，很大可能是统计信息出问题；如果在其他行上发现较大差距，则也有可能是非统计信息问题。 - - `select count(*)`。在执行计划中包含 `join` 等情况下，explain analyze 可能耗时过长；此时可以通过对 `TableScan`/`IndexScan` 上的条件进行 `select count(*)`，并对比 `explain` 结果中的 `row count` 信息，确定是不是统计信息的问题。 + - `select count(*)` 在执行计划中包含 `join` 等情况下，explain analyze 可能耗时过长；此时可以通过对 `TableScan`/`IndexScan` 上的条件进行 `select count(*)`，并对比 `explain` 结果中的 `row count` 信息，确定是不是统计信息的问题。 - 3.3.3 缓解问题 @@ -164,7 +164,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - 3.4.1 客户端报 `ERROR 1265(01000) Data Truncated` 错误。原因是 TiDB 内在计算 `Decimal` 类型处理精度的时候，和 MySQL 不兼容。该错误已于 v3.0.10 中修复 ([#14438](https://github.com/pingcap/tidb/pull/14438))，具体原因如下： - 在 MySQL 内，如果两个大精度 `Decimal` 做除法运算，超出最大小数精度时(`30`)，会只保留 `30` 位且不报错；TiDB 在计算结果上，也是这样实现的，但是在内部表示 `Decimal` 的结构体内，有一个表示小数精度的字段，还是保留的真实精度； + 在 MySQL 内，如果两个大精度 `Decimal` 做除法运算，超出最大小数精度时(`30`)，会只保留 `30` 位且不报错。TiDB 在计算结果上，也是这样实现的，但是在内部表示 `Decimal` 的结构体内，有一个表示小数精度的字段，还是保留的真实精度。 比如 `(0.1^30) / 10`，TiDB 和 MySQL 的结果都为 0，是正确的，因为精度最多 `30`；但是 TiDB 内表示精度的那个字段，还是 31； @@ -220,13 +220,13 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - 4.3.2 `scheduler too busy` - - 写入冲突严重，`latch wait duration` 比较高，查看监控： **Grafana** -> **TiKV-details** -> **scheduler prewrite** 或者 **scheduler commit** 的 `latch wait duration`。scheduler 写入任务堆积，导致超过了 `[storage] scheduler-pending-write-threshold = "100MB"` 设置的阈值。可通过查看 `MVCC_CONFLICT_COUNTER` 对应的 metric 来确认是否属于该情况。 + - 写入冲突严重，`latch wait duration` 比较高，查看监控：**Grafana** -> **TiKV-details** -> **scheduler prewrite** 或者 **scheduler commit** 的 `latch wait duration`。scheduler 写入任务堆积，导致超过了 `[storage] scheduler-pending-write-threshold = "100MB"` 设置的阈值。可通过查看 `MVCC_CONFLICT_COUNTER` 对应的 metric 来确认是否属于该情况。 - 写入慢导致写入堆积，该 TiKV 正在写入的数据超过了 `[storage] scheduler-pending-write-threshold = "100MB"` 设置的阈值。请参考 [4.5 TiKV 写入慢](#45-tikv-写入慢)。 - 4.3.3 `raftstore is busy`，主要是消息的处理速度没有跟上接收消息的速度。短时间的 `channel full` 不会影响服务，长时间持续出现该错误可能会导致 Leader 切换走。 - `append log` 遇到了 stall，参考 [4.3.1 客户端报 `server is busy` 错误](#43-客户端报-server-is-busy-错误)。 - - `append log duration` 比较高，导致处理消息不及时，可以参考 [4.5 TiKV 写入慢](#45-tikv-写入慢) 分析为什么 `append log duration` 比较高。 + - `append log duration` 比较高，导致处理消息不及时，可以参考 [4.5 TiKV 写入慢](#45-tikv-写入慢)分析为什么 `append log duration` 比较高。 - 瞬间收到大量消息（查看 TiKV Raft messages 面板），Raftstore 没处理过来，通常情况下短时间的 `channel full` 不会影响服务。 - 4.3.4 TiKV Coprocessor 排队，任务堆积超过了 `Coprocessor 线程数 * readpool.coprocessor.max-tasks-per-worker-[normal|low|high]`。大量大查询导致 Coprocessor 出现了堆积情况，需要确认是否由于执行计划变化而导致了大量扫表操作，请参考 [3.3 执行计划不对](#33-执行计划不对)。 @@ -246,7 +246,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles ### 4.5 TiKV 写入慢 -- 4.5.1 通过查看 TiKV gRPC 的 `prewrite`/`commit`/`raw-put`(仅限 raw kv 集群) duration 确认确实是 TiKV 写入慢了。通常情况下可以按照 [performance-map](https://github.com/pingcap/tidb-map/blob/master/maps/performance-map.png) 来定位到底哪个阶段慢了，下面列出几种常见的情况。 +- 4.5.1 通过查看 TiKV gRPC 的 `prewrite`/`commit`/`raw-put`（仅限 raw kv 集群）duration 确认确实是 TiKV 写入慢了。通常情况下可以按照 [performance-map](https://github.com/pingcap/tidb-map/blob/master/maps/performance-map.png) 来定位到底哪个阶段慢了，下面列出几种常见的情况。 - 4.5.2 scheduler CPU 繁忙（仅限 transaction kv）。prewrite/commit 的 `scheduler command duration` 比 `scheduler latch wait duration` + `storage async write duration` 更长，并且 scheduler worker CPU 比较高，例如超过 `scheduler-worker-pool-size` * 100% 的 80%，并且或者整个机器的 CPU 资源比较紧张。如果写入量很大，确认下是否 `[storage] scheduler-worker-pool-size` 配置得太小。其他情况，[需报 bug](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 @@ -309,7 +309,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - 5.2.3 TiDB 执行 SQL 时报 PD timeout： - - PD 没 Leader 或者有切换，参考 [5.2.1 PD 选举问题](#52-pd-选举问题) 和 [5.2.2 PD 选举问题](#52-pd-选举问题)。 + - PD 没 Leader 或者有切换，参考 [5.2.1 PD 选举问题](#52-pd-选举问题)和 [5.2.2 PD 选举问题](#52-pd-选举问题)。 - 网络问题，排查网络相关情况。通过监控 **Grafana** -> **blackbox_exporter** -> **ping latency** 确定 TiDB 到 PD Leader 的网络是否正常。 @@ -479,7 +479,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - 原因 2：如果目标数据库的校验和全是 0，表示没有发生任何导入，有可能是集群太忙无法接收任何数据。 - - 原因 3：如果数据源是由机器生成而不是从 [Mydumper](https://docs.pingcap.com/zh/tidb/v4.0/mydumper-overview) 备份的，需确保数据符合表的限制，例如： + - 原因 3：如果数据源是由机器生成而不是从 [Mydumper](https://docs.pingcap.com/zh/tidb/v4.0/mydumper-overview) 备份的，需确保数据符合表的限制。例如： - 自增 (AUTO_INCREMENT) 的列需要为正数，不能为 0。 - 单一键和主键 (UNIQUE and PRIMARY KEYs) 不能有重复的值。 @@ -516,7 +516,7 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles - 7.1.1 `GC life time is shorter than transaction duration`。事务执行时间太长，超过了 GC lifetime（默认为 10 分钟），可以通过修改系统变量 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-从-v50-版本开始引入) 来延长 life time，通常情况下不建议修改，因为延长时限可能导致大量老版本数据的堆积（如果有大量 `UPDATE` 和 `DELETE` 语句）。 -- 7.1.2 `txn takes too much time`。事务太长时间（超过 590s）没有提交，准备提交的时候报该错误。可以通过调大 `[tikv-client] max-txn-time-use = 590` 参数，以及调大 `GC life time` 来绕过该问题（如果确实有这个需求）。通常情况下，建议看看业务是否真的需要执行这么长时间的事务。 +- 7.1.2 `txn takes too much time`。 事务太长时间（超过 590s）没有提交，准备提交的时候报该错误。可以通过调大 `[tikv-client] max-txn-time-use = 590` 参数，以及调大 `GC life time` 来绕过该问题（如果确实有这个需求）。通常情况下，建议看看业务是否真的需要执行这么长时间的事务。 - 7.1.3 coprocessor.go 报 `request outdated`。发往 TiKV 的 Coprocessor 请求在 TiKV 端排队时间超过了 60s，直接返回该错误。需要排查 TiKV Coprocessor 为什么排队这么严重。 @@ -534,14 +534,14 @@ aliases: ['/docs-cn/dev/tidb-troubleshooting-map/','/docs-cn/dev/how-to/troubles ### 7.2 TiKV -- 7.2.1 `key is locked`。读写冲突，读请求碰到还未提交的数据，需要等待其提交之后才能读。少量这个错误对业务无影响，大量出现这个错误说明业务读写冲突比较严重。 +- 7.2.1 `key is locked` 读写冲突，读请求碰到还未提交的数据，需要等待其提交之后才能读。少量这个错误对业务无影响，大量出现这个错误说明业务读写冲突比较严重。 -- 7.2.2 `write conflict`。乐观事务中的写写冲突，同时多个事务对相同的 key 进行修改，只有一个事务会成功，其他事务会自动重取 timestamp 然后进行重试，不影响业务。如果业务冲突很严重可能会导致重试多次之后事务失败，这种情况下建议使用悲观锁。 +- 7.2.2 `write conflict` 乐观事务中的写写冲突，同时多个事务对相同的 key 进行修改，只有一个事务会成功，其他事务会自动重取 timestamp 然后进行重试，不影响业务。如果业务冲突很严重可能会导致重试多次之后事务失败，这种情况下建议使用悲观锁。 -- 7.2.3 `TxnLockNotFound`。事务提交太慢，过了 TTL（小事务默认 3s）时间之后被其他事务回滚了，该事务会自动重试，通常情况下对业务无感知。 +- 7.2.3 `TxnLockNotFound` 事务提交太慢，过了 TTL（小事务默认 3s）时间之后被其他事务回滚了，该事务会自动重试，通常情况下对业务无感知。 -- 7.2.4 `PessimisticLockNotFound`。类似 `TxnLockNotFound`，悲观事务提交太慢被其他事务回滚了。 +- 7.2.4 `PessimisticLockNotFound` 类似 `TxnLockNotFound`，悲观事务提交太慢被其他事务回滚了。 -- 7.2.5 `stale_epoch`。请求的 epoch 太旧了，TiDB 会更新路由之后再重新发送请求，业务无感知。epoch 在 Region 发生 split/merge 以及迁移副本的时候会变化。 +- 7.2.5 `stale_epoch` 请求的 epoch 太旧了，TiDB 会更新路由之后再重新发送请求，业务无感知。epoch 在 Region 发生 split/merge 以及迁移副本的时候会变化。 -- 7.2.6 `peer is not leader`。请求发到了非 Leader 的副本上，TiDB 会根据该错误更新本地路由（如果错误 response 里携带了最新 Leader 是哪个副本这一信息），并且重新发送请求到最新 Leader，一般情况下业务无感知。在 v3.0 后 TiDB 在原 Leader 请求失败时会尝试其他 peer，也会导致 TiKV 频繁出现 `not leader` 日志，可以通过查看 TiDB 对应 Region 的 `switch region peer to next due to send request fail` 日志，排查发送失败根本原因，参考 [7.1.4 TiDB](#71-tidb)。另外也可能是由于其他原因导致一些 Region 一直没有 Leader，请参考 [4.4 某些 TiKV 大量掉 Leader](#44-某些-tikv-大量掉-leader)。 +- 7.2.6 `peer is not leader` 请求发到了非 Leader 的副本上，TiDB 会根据该错误更新本地路由（如果错误 response 里携带了最新 Leader 是哪个副本这一信息），并且重新发送请求到最新 Leader，一般情况下业务无感知。在 v3.0 后 TiDB 在原 Leader 请求失败时会尝试其他 peer，也会导致 TiKV 频繁出现 `not leader` 日志，可以通过查看 TiDB 对应 Region 的 `switch region peer to next due to send request fail` 日志，排查发送失败根本原因，参考 [7.1.4 TiDB](#71-tidb)。另外也可能是由于其他原因导致一些 Region 一直没有 Leader，请参考 [4.4 某些 TiKV 大量掉 Leader](#44-某些-tikv-大量掉-leader)。 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 83bd63d469d2..feb445e30091 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -34,7 +34,7 @@ TiKV 配置文件比命令行参数支持更多的选项。你可以在 [etc/con ### `grpc-compression-type` -+ gRPC 消息的压缩算法，取值：none， deflate， gzip。 ++ gRPC 消息的压缩算法，取值：none，deflate，gzip。 + 默认值：none > **注意：** @@ -56,7 +56,7 @@ TiKV 配置文件比命令行参数支持更多的选项。你可以在 [etc/con ### `grpc-memory-pool-quota` + gRPC 可使用的内存大小限制。 -+ 默认值: 无限制 ++ 默认值：无限制 + 建议仅在出现内存不足 (OOM) 的情况下限制内存使用。需要注意，限制内存使用可能会导致卡顿。 ### `grpc-raft-conn-num` @@ -251,8 +251,7 @@ TiKV 配置文件比命令行参数支持更多的选项。你可以在 [etc/con ### `stack-size` -+ Coprocessor 线程池中线程的栈大小，默认值：10，单位：KiB|MiB|GiB。 -+ 类型：整数 + 单位 ++ Coprocessor 线程池中线程的栈大小。 + 默认值：10MB + 单位：KB|MB|GB + 最小值：2MB @@ -278,13 +277,13 @@ TiKV 配置文件比命令行参数支持更多的选项。你可以在 [etc/con + 写入数据队列的最大值，超过该值之后对于新的写入 TiKV 会返回 Server Is Busy 错误。 + 默认值：100MB -+ 单位: MB|GB ++ 单位：MB|GB ### `reserve-space` + TiKV 启动时预占额外空间的临时文件大小。临时文件名为 `space_placeholder_file`，位于 `storage.data-dir` 目录下。TiKV 磁盘空间耗尽无法正常启动需要紧急干预时，可以删除该文件，并且将 `reserve-space` 设置为 `0MB`。 + 默认值：5GB -+ 单位: MB|GB ++ 单位：MB|GB ### `enable-ttl` @@ -560,7 +559,7 @@ raftstore 相关的配置项。 ### `consistency-check-interval` -+ 触发一致性检查的时间间隔, 0 表示不启用。 ++ 触发一致性检查的时间间隔，0 表示不启用。 + 默认值：0s + 最小值：0 @@ -645,7 +644,7 @@ coprocessor 相关的配置项。 ### `split-region-on-table` -+ 开启按 table 分裂 Region的开关，建议仅在 TiDB 模式下使用。 ++ 开启按 table 分裂 Region 的开关，建议仅在 TiDB 模式下使用。 + 默认值：false ### `batch-split-limit` @@ -718,7 +717,7 @@ rocksdb 相关的配置项。 ### `wal-recovery-mode` -+ WAL 恢复模式，取值：0（TolerateCorruptedTailRecords），1（AbsoluteConsistency），2（PointInTimeRecovery），3（SkipAnyCorruptedRecords）。 ++ WAL 恢复模式，取值：0 (TolerateCorruptedTailRecords)，1 (AbsoluteConsistency)，2 (PointInTimeRecovery)，3 (SkipAnyCorruptedRecords)。 + 默认值：2 + 最小值：0 + 最大值：3 @@ -864,14 +863,14 @@ rocksdb defaultcf 相关的配置项。 ### `block-size` -+ rocksdb block size。 ++ rocksdb block size. + 默认值：64KB + 最小值：1KB + 单位：KB|MB|GB ### `block-cache-size` -+ rocksdb block cache size。 ++ rocksdb block cache size. + 默认值：机器总内存 * 25% + 最小值：0 + 单位：KB|MB|GB @@ -997,7 +996,7 @@ bloom filter 为每个 key 预留的长度。 ### `compaction-pri` + Compaction 优先类型 -+ 可选择值：3（MinOverlappingRatio），0（ByCompensatedSize），1（OldestLargestSeqFirst），2（OldestSmallestSeqFirst）。 ++ 可选择值：3 (MinOverlappingRatio)，0 (ByCompensatedSize)，1 (OldestLargestSeqFirst)，2 (OldestSmallestSeqFirst)。 + 默认值：3 ### `dynamic-level-bytes` @@ -1136,7 +1135,7 @@ rocksdb writecf 相关的配置项。 ### `block-cache-size` -+ block cache size。 ++ block cache size. + 默认值：机器总内存 * 15% + 单位：MB|GB @@ -1173,7 +1172,7 @@ rocksdb lockcf 相关配置项。 ### `block-cache-size` -+ block cache size。 ++ block cache size. + 默认值：机器总内存 * 2% + 单位：MB|GB diff --git a/tikv-overview.md b/tikv-overview.md index 1beef85a8925..47fe9c368512 100644 --- a/tikv-overview.md +++ b/tikv-overview.md @@ -5,7 +5,7 @@ aliases: ['/docs-cn/dev/tikv-overview/'] # TiKV 简介 -TiKV 是一个分布式事务型的键值数据库，提供了满足 ACID 约束的分布式事务接口，并且通过 [Raft 协议](https://raft.github.io/raft.pdf) 保证了多副本数据一致性以及高可用。TiKV 作为 TiDB 的存储层，为用户写入 TiDB 的数据提供了持久化以及读写服务，同时还存储了 TiDB 的统计信息数据。 +TiKV 是一个分布式事务型的键值数据库，提供了满足 ACID 约束的分布式事务接口，并且通过 [Raft 协议](https://raft.github.io/raft.pdf)保证了多副本数据一致性以及高可用。TiKV 作为 TiDB 的存储层，为用户写入 TiDB 的数据提供了持久化以及读写服务，同时还存储了 TiDB 的统计信息数据。 ## 整体架构 diff --git a/tispark-overview.md b/tispark-overview.md index 5838c145ab75..ad03c530b8d6 100644 --- a/tispark-overview.md +++ b/tispark-overview.md @@ -7,7 +7,7 @@ aliases: ['/docs-cn/dev/tispark-overview/','/docs-cn/dev/reference/tispark/'] TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。它借助 Spark 平台，同时融合 TiKV 分布式集群的优势，和 TiDB 一起为用户一站式解决 HTAP (Hybrid Transactional/Analytical Processing) 的需求。TiSpark 依赖于 TiKV 集群和 Placement Driver (PD)，也需要你搭建一个 Spark 集群。 -本文简单介绍如何部署和使用 TiSpark。本文假设你对 Spark 有基本认知。你可以参阅 [Apache Spark 官网](https://spark.apache.org/docs/latest/index.html) 了解 Spark 的相关信息。 +本文简单介绍如何部署和使用 TiSpark。本文假设你对 Spark 有基本认知。你可以参阅 [Apache Spark 官网](https://spark.apache.org/docs/latest/index.html)了解 Spark 的相关信息。 ## 概述 @@ -15,7 +15,7 @@ TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP ![TiSpark Architecture](/media/tispark-architecture.png) -+ TiSpark 深度整合了 Spark Catalyst 引擎, 可以对计算提供精确的控制，使 Spark 能够高效的读取 TiKV 中的数据，提供索引支持以实现高速的点查。 ++ TiSpark 深度整合了 Spark Catalyst 引擎，可以对计算提供精确的控制，使 Spark 能够高效的读取 TiKV 中的数据，提供索引支持以实现高速的点查。 + 通过多种计算下推减少 Spark SQL 需要处理的数据大小，以加速查询；利用 TiDB 的内建的统计信息选择更优的查询计划。 + 从数据集群的角度看，TiSpark + TiDB 可以让用户无需进行脆弱和难以维护的 ETL，直接在同一个平台进行事务和分析两种工作，简化了系统架构和运维。 + 用户借助 TiSpark 项目可以在 TiDB 上使用 Spark 生态圈提供的多种工具进行数据处理。例如，使用 TiSpark 进行数据分析和 ETL；使用 TiKV 作为机器学习的数据源；借助调度系统产生定时报表等等。 @@ -31,7 +31,7 @@ TiSpark 可以在 YARN，Mesos，Standalone 等任意 Spark 模式下运行。 ## 推荐配置 -本部分描述了 TiKV 与 TiSpark 集群分开部署、Spark 与 TiSpark 集群独立部署，以及TiSpark 与 TiKV 集群混合部署的建议配置。 +本部分描述了 TiKV 与 TiSpark 集群分开部署、Spark 与 TiSpark 集群独立部署，以及 TiSpark 与 TiKV 集群混合部署的建议配置。 ### TiKV 与 TiSpark 集群分开部署的配置 @@ -367,7 +367,7 @@ TiSpark 可以使用 TiDB 的统计信息： - Q. Spark 执行中报 warning：WARN ObjectStore:568 - Failed to get database - A. Warning 忽略即可，原因是 Spark 找不到对应的 hive 库，因为这个库是在 TIKV 中，而不是在 hive 中。可以考虑调整 [log4j 日志](https://github.com/pingcap/tidb-docker-compose/blob/master/tispark/conf/log4j.properties#L43)，将该参数添加到 spark 下 conf 里 log4j 文件(如果后缀是 template 那先 mv 成后缀 properties)。 + A. Warning 忽略即可，原因是 Spark 找不到对应的 hive 库，因为这个库是在 TIKV 中，而不是在 hive 中。可以考虑调整 [log4j 日志](https://github.com/pingcap/tidb-docker-compose/blob/master/tispark/conf/log4j.properties#L43)，将该参数添加到 spark 下 conf 里 log4j 文件（如果后缀是 template 那先 mv 成后缀 properties）。 - Q. Spark 执行中报 java.sql.BatchUpdateException: Data Truncated @@ -377,6 +377,6 @@ TiSpark 可以使用 TiDB 的统计信息： A. TiSpark 通过读取 hive-site 里的 meta 来搜寻 hive 的库。如果搜寻不到，就通过读取 tidb meta 搜寻 tidb 库。如果不需要该行为，可不在 hive site 中配置 hive 的 meta。 -- Q. TiSpark 执行 Spark 任务时报：Error：java.io.InvalidClassException: com.pingcap.tikv.region.TiRegion; local class incompatible: stream classdesc serialVersionUID ... +- Q. TiSpark 执行 Spark 任务时报："Error：java.io.InvalidClassException: com.pingcap.tikv.region.TiRegion; local class incompatible: stream classdesc serialVersionUID ..." A. 该报错日志中显示 serialVersionUID 冲突，说明存在不同版本的 class 和 TiRegion。因为 TiRegion 是 TiSpark 独有的，所以可能存在多个版本的 TiSpark 包。要解决该报错，请确保集群中各节点的 TiSpark 依赖包版本一致。 diff --git a/transaction-overview.md b/transaction-overview.md index b4f73b4d096d..12ce5719bd8c 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -180,7 +180,7 @@ SET GLOBAL autocommit = 0; > > 有些语句是隐式提交的。例如，执行 `[BEGIN|START TRANCATION]` 语句时，TiDB 会隐式提交上一个事务，并开启一个新的事务以满足 MySQL 兼容性的需求。详情参见 [implicit commit](https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html)。 -TiDB 可以显式地使用事务（通过 `[BEGIN|START TRANSACTION]`/`COMMIT` 语句定义事务的开始和结束) 或者隐式地使用事务 (`SET autocommit = 1`)。 +TiDB 可以显式地使用事务（通过 `[BEGIN|START TRANSACTION]`/`COMMIT` 语句定义事务的开始和结束）或者隐式地使用事务 (`SET autocommit = 1`)。 在自动提交状态下，使用 `[BEGIN|START TRANSACTION]` 语句会显式地开启一个事务，同时也会禁用自动提交，使隐式事务变成显式事务。直到执行 `COMMIT` 或 `ROLLBACK` 语句时才会恢复到此前默认的自动提交状态。 @@ -319,7 +319,7 @@ START TRANSACTION WITH CAUSAL CONSISTENCY ONLY; 默认情况下，TiDB 保证线性一致性。在线性一致性的情况下，如果事务 2 在事务 1 提交完成后提交，逻辑上事务 2 就应该在事务 1 后发生。 -因果一致性弱于线性一致性。在因果一致性的情况下， 只有事务 1 和事务 2 加锁或写入的数据有交集时（即事务 1 和事务 2 存在数据库可知的因果关系时），才能保证事务的提交顺序与事务的发生顺序保持一致。目前暂不支持传入数据库外部的因果关系。 +因果一致性弱于线性一致性。在因果一致性的情况下，只有事务 1 和事务 2 加锁或写入的数据有交集时（即事务 1 和事务 2 存在数据库可知的因果关系时），才能保证事务的提交顺序与事务的发生顺序保持一致。目前暂不支持传入数据库外部的因果关系。 采用因果一致性的两个事务有以下特性： @@ -329,7 +329,7 @@ START TRANSACTION WITH CAUSAL CONSISTENCY ONLY; ### 有潜在因果关系的事务之间的逻辑顺序与物理提交顺序一致 -假设事务 1 和 事务 2 都采用因果一致性，并先后执行如下语句： +假设事务 1 和事务 2 都采用因果一致性，并先后执行如下语句： | 事务 1 | 事务 2 | |-------|-------| @@ -340,11 +340,11 @@ START TRANSACTION WITH CAUSAL CONSISTENCY ONLY; | | UPDATE t SET v = 2 WHERE id = 1 | | | COMMIT | -上面的例子中，事务 1 对 `id = 1` 的记录加了锁，事务 2 的事务对 `id = 1` 的记录进行了修改，所以事务 1 和 事务 2 有潜在的因果关系。所以即使用因果一致性开启事务，只要事务 2 在事务 1 提交成功后才提交，逻辑上事务 2 就必定比事务 1 晚发生。因此，不存在某个事务读到了事务 2 对 `id = 1` 记录的修改，但却没有读到事务 1 对 `id = 2` 记录的修改的情况。 +上面的例子中，事务 1 对 `id = 1` 的记录加了锁，事务 2 的事务对 `id = 1` 的记录进行了修改，所以事务 1 和事务 2 有潜在的因果关系。所以即使用因果一致性开启事务，只要事务 2 在事务 1 提交成功后才提交，逻辑上事务 2 就必定比事务 1 晚发生。因此，不存在某个事务读到了事务 2 对 `id = 1` 记录的修改，但却没有读到事务 1 对 `id = 2` 记录的修改的情况。 ### 无因果关系的事务之间的逻辑顺序与物理提交顺序不保证一致 -假设 `id = 1` 和 `id = 2` 的记录最初值都为 0，事务 1 和 事务 2 都采用因果一致性，并先后执行如下语句： +假设 `id = 1` 和 `id = 2` 的记录最初值都为 0，事务 1 和事务 2 都采用因果一致性，并先后执行如下语句： | 事务 1 | 事务 2 | 事务 3 | |-------|-------|-------| @@ -362,7 +362,7 @@ START TRANSACTION WITH CAUSAL CONSISTENCY ONLY; ### 不加锁的读取不产生因果关系 -假设事务 1 和 事务 2 都采用因果一致性，并先后执行如下语句： +假设事务 1 和事务 2 都采用因果一致性，并先后执行如下语句： | 事务 1 | 事务 2 | |-------|-------| diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index a51fa5f60276..998c8f02c584 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -53,7 +53,7 @@ aliases: ['/docs-cn/dev/troubleshoot-cpu-issues/'] * 选举不出 leader。PD 日志中有 `"lease is not expired"`，见 issues [https://github.com/etcd-io/etcd/issues/10355](https://github.com/etcd-io/etcd/issues/10355)。v3.0.x 版本和 v2.1.19 版本已解决该问题，见案例 [case-875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)。 -* 选举慢。Region 加载时间长，从 PD 日志中 `grep "regions cost"`（例如日志中可能是 `load 460927 regions cost 11.77099s`）, 如果出现秒级，则说明较慢，v3.0 版本可开启 Region Storage（设置 `use-region-storage` 为 `true`），该特性能极大缩短加载 Region 的时间，见案例 [case-429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md)。 +* 选举慢。Region 加载时间长，从 PD 日志中 `grep "regions cost"`（例如日志中可能是 `load 460927 regions cost 11.77099s`），如果出现秒级，则说明较慢，v3.0 版本可开启 Region Storage（设置 `use-region-storage` 为 `true`），该特性能极大缩短加载 Region 的时间，见案例 [case-429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md)。 * TiDB 与 PD 之间的网络问题，应排查网络相关情况。通过监控 Grafana -> **blackbox_exporter** -> **ping latency** 确定 TiDB 到 PD leader 的网络是否正常。 diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md index 780f2fd745f1..c67accc70ea7 100644 --- a/troubleshoot-high-disk-io.md +++ b/troubleshoot-high-disk-io.md @@ -18,7 +18,7 @@ aliases: ['/docs-cn/dev/troubleshoot-high-disk-io/'] #### 第一类面板 -在 `Overview` > `System Info` > `IO Util` 中，可以看到集群中每个机器的 I/O 情况，该指标和 Linux iostat 监控中的 util 类似，百分比越高代表磁盘 I/O 占用越高： +在 `Overview` > `System Info` > `IO Util` 中，可以看到集群中每个机器的 I/O 情况，该指标和 Linux iostat 监控中的 util 类似，百分比越高代表磁盘 I/O 占用越高： - 如果监控中只有一台机器的 I/O 高，那么可以辅助判断当前有读写热点。 - 如果监控中大部分机器的 I/O 都高，那么集群现在有高 I/O 负载存在。 @@ -71,7 +71,7 @@ TiDB 集群主要的持久化组件是 TiKV 集群，一个 TiKV 包含两个 Ro - TiKV RocksDB 日志出现 `write stall`。 - 可能是 `level0 sst` 太多导致 stall。可以添加参数 `[rocksdb] max-sub-compactI/Ons = 2（或者 3）` 加快 level0 sst 往下 compact 的速度，该参数的意思是将 从 level0 到 level1 的 compaction 任务最多切成 `max-sub-compactions` 个子任务交给多线程并发执行。 + 可能是 `level0 sst` 太多导致 stall。可以添加参数 `[rocksdb] max-sub-compactI/Ons = 2（或者 3）` 加快 level0 sst 往下 compact 的速度，该参数的意思是将从 level0 到 level1 的 compaction 任务最多切成 `max-sub-compactions` 个子任务交给多线程并发执行。 如果磁盘 I/O 能力持续跟不上写入，建议扩容。如果磁盘的吞吐达到了上限（例如 SATA SSD 的吞吐相对 NVME SSD 会低很多）导致 write stall，但是 CPU 资源又比较充足，可以尝试采用压缩率更高的压缩算法来缓解磁盘的压力，用 CPU 资源换磁盘资源。 diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index 519ddd8462cb..46f47802235d 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -30,9 +30,9 @@ TiKV 的读取请求分为两类： ## TiKV 线程池调优 -* gRPC 线程池的大小默认配置（`server.grpc-concurrency`）是 4。由于 gRPC 线程池几乎不会有多少计算开销，它主要负责网络 IO、反序列化请求，因此该配置通常不需要调整。 +* gRPC 线程池的大小默认配置 (`server.grpc-concurrency`) 是 4。由于 gRPC 线程池几乎不会有多少计算开销，它主要负责网络 IO、反序列化请求，因此该配置通常不需要调整。 - - 如果部署的机器 CPU 核数特别少（小于等于 8），可以考虑将该配置（`server.grpc-concurrency`）设置为 2。 + - 如果部署的机器 CPU 核数特别少（小于等于 8），可以考虑将该配置 (`server.grpc-concurrency`) 设置为 2。 - 如果机器配置很高，并且 TiKV 承担了非常大量的读写请求，观察到 Grafana 上的监控 Thread CPU 的 gRPC poll CPU 的数值超过了 server.grpc-concurrency 大小的 80%，那么可以考虑适当调大 `server.grpc-concurrency` 以控制该线程池使用率在 80% 以下（即 Grafana 上的指标低于 `80% * server.grpc-concurrency` 的值）。 * Scheduler 线程池的大小配置 (`storage.scheduler-worker-pool-size`) 在 TiKV 检测到机器 CPU 核数大于等于 16 时默认为 8，小于 16 时默认为 4。它主要用于将复杂的事务请求转化为简单的 key-value 读写。但是 **scheduler 线程池本身不进行任何写操作**。 @@ -42,13 +42,13 @@ TiKV 的读取请求分为两类： 通常来说为了避免过多的线程切换，最好确保 scheduler 线程池的利用率保持在 50%～75% 之间。（如果线程池大小为 8 的话，那么 Grafana 上的 TiKV-Details.Thread CPU.scheduler worker CPU 应当在 400%～600% 之间较为合理） -* Raftstore 线程池是 TiKV 最为复杂的一个线程池，默认大小（`raftstore.store-pool-size`）为 2，所有的写请求都会先在 Raftstore 线程 fsync 的方式写入 RocksDB（除非手动将 `raftstore.sync-log` 设置为 false；而 `raftstore.sync-log` 设置为 false，可以提升一部分写性能，但也会增加在机器故障时数据丢失的风险）。 +* Raftstore 线程池是 TiKV 最为复杂的一个线程池，默认大小 (`raftstore.store-pool-size`) 为 2，所有的写请求都会先在 Raftstore 线程 fsync 的方式写入 RocksDB（除非手动将 `raftstore.sync-log` 设置为 false；而 `raftstore.sync-log` 设置为 false，可以提升一部分写性能，但也会增加在机器故障时数据丢失的风险）。 由于存在 I/O，Raftstore 线程理论上不可能达到 100% 的 CPU。为了尽可能地减少写磁盘次数，将多个写请求攒在一起写入 RocksDB，最好控制其整体 CPU 使用在 60% 以下（按照线程数默认值 2，则 Grafana 监控上的 TiKV-Details.Thread CPU.Raft store CPU 上的数值控制在 120% 以内较为合理）。不要为了提升写性能盲目增大 Raftstore 线程池大小，这样可能会适得其反，增加了磁盘负担让性能变差。 -* UnifyReadPool 负责处理所有的读取请求。默认配置（`readpool.unified.max-thread-count`）大小为机器 CPU 数的 80% （如机器为 16 核，则默认线程池大小为 12）。 +* UnifyReadPool 负责处理所有的读取请求。默认配置 (`readpool.unified.max-thread-count`) 大小为机器 CPU 数的 80% （如机器为 16 核，则默认线程池大小为 12）。 - 通常建议根据业务负载特性调整其 CPU 使用率在线程池大小的 60%～90% 之间 (如果用户 Grafana 上 TiKV-Details.Thread CPU.Unified read pool CPU 的峰值不超过 800%， 那么建议用户将 `readpool.unified.max-thread-count` 设置为 10，过多的线程数会造成更频繁的线程切换，并且抢占其他线程池的资源)。 + 通常建议根据业务负载特性调整其 CPU 使用率在线程池大小的 60%～90% 之间（如果用户 Grafana 上 TiKV-Details.Thread CPU.Unified read pool CPU 的峰值不超过 800%，那么建议用户将 `readpool.unified.max-thread-count` 设置为 10，过多的线程数会造成更频繁的线程切换，并且抢占其他线程池的资源）。 * RocksDB 线程池是 RocksDB 进行 Compact 和 Flush 任务的线程池，通常不需要配置。 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index d128de327417..596402d63cc6 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -111,7 +111,7 @@ tiup update cluster > > 升级到 5.1 版本前，请确认已在 4.0 修改的参数在 5.1 版本中是兼容的，可参考 [TiKV 配置文件描述](/tikv-configuration-file.md)。 > -> 以下 TiKV 参数在 TiDB v5.1 已废弃。如果在原集群配置过以下参数，需要通过 `edit-config` 编辑模式删除这些参数: +> 以下 TiKV 参数在 TiDB v5.1 已废弃。如果在原集群配置过以下参数，需要通过 `edit-config` 编辑模式删除这些参数： > > - pessimistic-txn.enabled > - server.request-batch-enable-cross-command diff --git a/views.md b/views.md index 66a24f34df7a..753585abcd87 100644 --- a/views.md +++ b/views.md @@ -38,7 +38,7 @@ show create view v; ### 查询 `INFORMATION_SCHEMA.VIEWS` 表 -示例: +示例： {{< copyable "sql" >}} @@ -59,7 +59,7 @@ select * from information_schema.views; ### 查询 HTTP API -示例: +示例： {{< copyable "" >}} diff --git a/whats-new-in-tidb-4.0.md b/whats-new-in-tidb-4.0.md index 736257f84d64..4a532c39e7b8 100644 --- a/whats-new-in-tidb-4.0.md +++ b/whats-new-in-tidb-4.0.md @@ -20,7 +20,7 @@ aliases: ['/docs-cn/dev/whats-new-in-tidb-4.0/'] ## TiDB Dashboard + DBA 通过 [TiDB Dashboard](/dashboard/dashboard-intro.md) UI 可以快速了解集群的集群拓扑、配置信息、日志信息、硬件信息、操作系统信息、慢查询信息、SQL 访问信息、诊断报告信息等，帮助 DBA 通过 SQL 快速了解、分析系统的各项指标，具体信息如下： - - Cluster Info，提供集群中所有组件，包括： TiDB、TiKV、PD、TiFlash 运行状态及其所在主机的运行状态。 + - Cluster Info，提供集群中所有组件，包括：TiDB、TiKV、PD、TiFlash 运行状态及其所在主机的运行状态。 - Key Visualizer，系统可视化输出 TiDB 集群一段时间内的流量情况，用于 DBA 分析 TiDB 集群的使用模式和排查流量热点。 - SQL Statements，记录当系统执行的所有 SQL 以及 SQL 相关的统计信息，包括：执行次数、执行时间汇总等，帮助用户快速分析系统的 SQL 执行状况，判断系统中有哪些热点 SQL 语句等。 - Slow Queries，汇总集群中所有的慢查询语句，帮助用户快速定位慢查询语句。 @@ -29,10 +29,10 @@ aliases: ['/docs-cn/dev/whats-new-in-tidb-4.0/'] ## 部署运维工具 -TiUP 是 4.0 版本中新推出的包管理器的工具，主要用于管理 TiDB 生态内的所有的包，提供组件管理、Playground、Cluster、TUF、离线部署等功能，将安装、部署、运维 TiDB 工具化，提升 DBA 部署、运维 TiDB 的效率。详情参阅：[TiUP](/tiup/tiup-overview.md)，具体的功能如下： +TiUP 是 4.0 版本中新推出的包管理器的工具，主要用于管理 TiDB 生态内的所有的包，提供组件管理、Playground、Cluster、TUF、离线部署等功能，将安装、部署、运维 TiDB 工具化，提升 DBA 部署、运维 TiDB 的效率。详情参阅：[TiUP](/tiup/tiup-overview.md)。具体的功能如下： - 组件管理功能，提供一键式组件信息查询、安装、升级、卸载等功能，方便 DBA 管理 TiDB 的所有组件。 -- 集群管理功能 (Cluster)：提供一键式 TiDB 集群的部署、运维 TiDB 功能，包括：安装、部署、扩容、缩容、升级、配置变更、启动、停止、重启，查询集群状信息等，支持管理多个 TiDB 集群。 +- 集群管理功能 (Cluster)：提供一键式 TiDB 集群的部署、运维 TiDB 功能。包括：安装、部署、扩容、缩容、升级、配置变更、启动、停止、重启，查询集群状信息等，支持管理多个 TiDB 集群。 - 本地部署功能 (Playground): 提供快速在本地部署一个 TiDB 集群，快速体验、了解 TiDB 的基本功能，注意：此功能仅用于快速了解 TiDB，不适合上生产。 - 私有镜像管理 (Mirror): 当无法通过公网访问 TiUP 官方镜像时，TiUP 提供构建私有镜像的方案，帮助用户构建私有镜像及提供离线部署部署的功能。 - 性能测试功能 (Benchmark): 提供一键部署性能测试工具的功能，主要提供 TPC-C、TPC-H 两种性能测试的 workload 。 @@ -53,7 +53,7 @@ TiUP 是 4.0 版本中新推出的包管理器的工具，主要用于管理 TiD - 优化 `EXPLAIN` 和 `EXPLAIN ANALYZE` 的输出结果，显示更多的信息，提升排查问题的效率。详情参阅：[Explain Analyze](/sql-statements/sql-statement-explain-analyze.md)，[Explain](/sql-statements/sql-statement-explain.md)。 - 支持 Index Merge 功能，Index Merge 是一种新的表访问方式，当查询只涉及到单张表时，优化器会自动根据查询条件读取多个索引数据并对结果求并集，提升查询单张表时的性能。详情参阅：[Index Merge](/explain-overview.md#indexmerge-示例)。 - 支持 AutoRandom Key 作为 TiDB 在列属性上的扩展语法，AutoRandom 被设计用于解决自增主键列的写热点问题，为使用自增主键列的用户提供最低成本的 MySQL 迁移方案。详情参阅：[AutoRandom Key](/auto-random.md)。 -- 新增集群拓扑、配置信息、日志信息、硬件信息、操作系统信息、慢查询信息等系统表等，帮助 DBA 通过 SQL 快速了解、分析系统的各项指标，详情参阅：[information_schema](/information-schema/information-schema.md)，具体信息如下： +- 新增集群拓扑、配置信息、日志信息、硬件信息、操作系统信息、慢查询信息等系统表等，帮助 DBA 通过 SQL 快速了解、分析系统的各项指标，详情参阅：[information_schema](/information-schema/information-schema.md)。具体信息如下： - 新增集群拓扑、配置、日志、硬件、操作系统等信息表，帮助 DBA 快速了集群配置、状态信息： @@ -71,7 +71,7 @@ TiUP 是 4.0 版本中新推出的包管理器的工具，主要用于管理 TiD ## 字符集及排序规则 -在 TiDB 4.0 的新集群中，支持大小写和口音不敏感的排序规则 `utf8mb4_general_ci` 及 `utf8_general_ci`，详情参阅: [字符集及排序规则](/character-set-and-collation.md)。 +在 TiDB 4.0 的新集群中，支持大小写和口音不敏感的排序规则 `utf8mb4_general_ci` 及 `utf8_general_ci`，详情参阅：[字符集及排序规则](/character-set-and-collation.md)。 ## 安全 @@ -90,4 +90,4 @@ TiUP 是 4.0 版本中新推出的包管理器的工具，主要用于管理 TiD ## TiCDC -TiCDC 支持通过拉取 TiKV 变更日志实现 TiDB 集群之间数据同步，支持数据的高可靠、服务的高可用能力，确保数据不会丢失。用户可以通过订阅的方式订阅数据的变更信息，系统会自动将数据推送到下游系统，当前仅支持 MySQL 协议的数据库（例如：MySQL、TiDB)，Kafka 及 Pulsar 作为 TiCDC 的下游，同时用户也可以通过 TiCDC 提供的[开放数据协议](/ticdc/ticdc-open-protocol.md)自行扩展支持的下游系统。详情参阅：[TiCDC](/ticdc//ticdc-overview.md)。 +TiCDC 支持通过拉取 TiKV 变更日志实现 TiDB 集群之间数据同步，支持数据的高可靠、服务的高可用能力，确保数据不会丢失。用户可以通过订阅的方式订阅数据的变更信息，系统会自动将数据推送到下游系统，当前仅支持 MySQL 协议的数据库（例如：MySQL、TiDB），Kafka 及 Pulsar 作为 TiCDC 的下游，同时用户也可以通过 TiCDC 提供的[开放数据协议](/ticdc/ticdc-open-protocol.md)自行扩展支持的下游系统。详情参阅：[TiCDC](/ticdc//ticdc-overview.md)。