From 63305cdfec9dcf21b42533d5dff44be132b926a6 Mon Sep 17 00:00:00 2001 From: lilin90 Date: Thu, 21 May 2020 17:16:17 +0800 Subject: [PATCH 01/13] toc: remove inapplicable dm topics --- TOC.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/TOC.md b/TOC.md index 12691e8d7f8f..19eba99df3e3 100644 --- a/TOC.md +++ b/TOC.md @@ -59,12 +59,10 @@ + [线上负载与 ADD INDEX 相互影响测试](/benchmark/online-workloads-and-add-index-operations.md) + 数据迁移 + [支持的迁移路径](/ecosystem-tool-user-guide.md) @王相 - + [从 Oracle 迁移至 TiDB](/migrate-from-oracle-to-tidb.md) @王相 + 从 MySQL 迁移至 TiDB + [从 CSV 文件迁移](/migrate-from-mysql-csv-files.md) @栾成 + [从 Mydumper 文件迁移](/migrate-from-mysql-mydumper-files.md) @栾成 + [使用 DM 工具从 Amazon Aurora MySQL 迁移](/migrate-from-aurora-mysql-database.md) @张学成，王相 - + [从 PostgreSQL 迁移至 TiDB](/migrate-from-postgresql-to-tidb.md) @王相 + [从 CSV 文件迁移至 TiDB](/tidb-lightning/migrate-from-csv-using-tidb-lightning.md) @王相 + 运维操作 + 升级 TiDB 版本 From c37e80e2ca0af6440382bf717cf299f3d8d834d9 Mon Sep 17 00:00:00 2001 From: lilin90 Date: Thu, 21 May 2020 17:18:09 +0800 Subject: [PATCH 02/13] Remove two inapplicable files --- migrate-from-oracle-to-tidb.md | 0 migrate-from-postgresql-to-tidb.md | 0 2 files changed, 0 insertions(+), 0 deletions(-) delete mode 100644 migrate-from-oracle-to-tidb.md delete mode 100644 migrate-from-postgresql-to-tidb.md diff --git a/migrate-from-oracle-to-tidb.md b/migrate-from-oracle-to-tidb.md deleted file mode 100644 index e69de29bb2d1..000000000000 diff --git a/migrate-from-postgresql-to-tidb.md b/migrate-from-postgresql-to-tidb.md deleted file mode 100644 index e69de29bb2d1..000000000000 From 2b3122e69e0d060b19ad93b8b59a49889c1a5b53 Mon Sep 17 00:00:00 2001 From: 3pointer Date: Thu, 21 May 2020 19:34:25 +0800 Subject: [PATCH 03/13] Add lightning faq (#3176) --- troubleshoot-tidb-lightning.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/troubleshoot-tidb-lightning.md b/troubleshoot-tidb-lightning.md index 7925b2f56ffc..a43b36df52b3 100644 --- a/troubleshoot-tidb-lightning.md +++ b/troubleshoot-tidb-lightning.md @@ -133,3 +133,11 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= 3. 确保整个集群使用的是同一最新版本的 `tzdata` (2018i 或更高版本)。 如果你使用的是 CentOS 机器，你可以运行 `yum info tzdata` 命令查看 `tzdata` 的版本及是否有更新。然后运行 `yum upgrade tzdata` 命令升级 `tzdata`。 + +## `[Error 8025: entry too large, the max entry size is 6291456]` + +**原因**：TiDB Lightning 生成的单行 KV 超过了 TiDB 的限制。 + +**解决办法**: + +目前无法绕过 TiDB 的限制，只能忽略这张表，确保其它表顺利导入。 From 65bb0b12b35528c0ea80f0d236b3c8e76c4a5250 Mon Sep 17 00:00:00 2001 From: Ran Date: Thu, 21 May 2020 22:31:20 +0800 Subject: [PATCH 04/13] .github: add three github action workflows (#3213) --- .github/workflows/add-docs-sig-issue.yml | 19 +++++++++++++++++++ .github/workflows/add-docs-sig-pr.yml | 19 +++++++++++++++++++ .github/workflows/translation-welcome.yml | 23 +++++++++++++++++++++++ 3 files changed, 61 insertions(+) create mode 100644 .github/workflows/add-docs-sig-issue.yml create mode 100644 .github/workflows/add-docs-sig-pr.yml create mode 100644 .github/workflows/translation-welcome.yml diff --git a/.github/workflows/add-docs-sig-issue.yml b/.github/workflows/add-docs-sig-issue.yml new file mode 100644 index 000000000000..3d9a649c020b --- /dev/null +++ b/.github/workflows/add-docs-sig-issue.yml @@ -0,0 +1,19 @@ +name: Auto Assign to Project + +on: + issue: + types: [opened] +env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + +jobs: + assign_one_project: + runs-on: ubuntu-latest + name: Assign to Docs SIG Project + steps: + - name: Assign NEW issues to Docs SIG project + uses: srggrs/assign-one-project-github-action@1.2.0 + if: github.event.action == 'opened' + with: + project: 'https://github.com/pingcap/docs-cn/projects/1' + column_name: 'Issue: Backlog' diff --git a/.github/workflows/add-docs-sig-pr.yml b/.github/workflows/add-docs-sig-pr.yml new file mode 100644 index 000000000000..20999080060b --- /dev/null +++ b/.github/workflows/add-docs-sig-pr.yml @@ -0,0 +1,19 @@ +name: Auto Assign to Project + +on: + pull_request: + types: [opened] +env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + +jobs: + assign_one_project: + runs-on: ubuntu-latest + name: Assign to Docs SIG Project + steps: + - name: Assign NEW pull requests to Docs SIG project + uses: srggrs/assign-one-project-github-action@1.2.0 + if: github.event.action == 'opened' + with: + project: 'https://github.com/pingcap/docs-cn/projects/1' + column_name: 'PR: In Progress' diff --git a/.github/workflows/translation-welcome.yml b/.github/workflows/translation-welcome.yml new file mode 100644 index 000000000000..7c717165b90c --- /dev/null +++ b/.github/workflows/translation-welcome.yml @@ -0,0 +1,23 @@ +name: Translation Welcome + +on: + issues: + types: [unlabeled, labeled] + pull_request: + types: [unlabeled, labeled] +env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + +jobs: + assign_one_project: + runs-on: ubuntu-latest + name: Auto Add to Project + steps: + - name: Add translation-welcome PRs/Issues to Project + uses: srggrs/assign-one-project-github-action@1.2.0 + if: | + contains(github.event.issue.labels.*.name, 'translation/welcome') || + contains(github.event.pull_request.labels.*.name, 'translation/welcome') + with: + project: 'https://github.com/pingcap/docs-cn/projects/2' + column_name: 'To do' From 07d6e2d40a7f404cc8a7ff48159fcce2d9a1b103 Mon Sep 17 00:00:00 2001 From: Ran Date: Fri, 22 May 2020 10:01:10 +0800 Subject: [PATCH 05/13] .github: update workflow to auto assign project (#3229) --- .github/workflows/add-docs-sig-issue.yml | 19 ----------- .github/workflows/add-docs-sig-pr.yml | 19 ----------- .github/workflows/assign-to-project.yml | 39 +++++++++++++++++++++++ .github/workflows/translation-welcome.yml | 23 ------------- 4 files changed, 39 insertions(+), 61 deletions(-) delete mode 100644 .github/workflows/add-docs-sig-issue.yml delete mode 100644 .github/workflows/add-docs-sig-pr.yml create mode 100644 .github/workflows/assign-to-project.yml delete mode 100644 .github/workflows/translation-welcome.yml diff --git a/.github/workflows/add-docs-sig-issue.yml b/.github/workflows/add-docs-sig-issue.yml deleted file mode 100644 index 3d9a649c020b..000000000000 --- a/.github/workflows/add-docs-sig-issue.yml +++ /dev/null @@ -1,19 +0,0 @@ -name: Auto Assign to Project - -on: - issue: - types: [opened] -env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - -jobs: - assign_one_project: - runs-on: ubuntu-latest - name: Assign to Docs SIG Project - steps: - - name: Assign NEW issues to Docs SIG project - uses: srggrs/assign-one-project-github-action@1.2.0 - if: github.event.action == 'opened' - with: - project: 'https://github.com/pingcap/docs-cn/projects/1' - column_name: 'Issue: Backlog' diff --git a/.github/workflows/add-docs-sig-pr.yml b/.github/workflows/add-docs-sig-pr.yml deleted file mode 100644 index 20999080060b..000000000000 --- a/.github/workflows/add-docs-sig-pr.yml +++ /dev/null @@ -1,19 +0,0 @@ -name: Auto Assign to Project - -on: - pull_request: - types: [opened] -env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - -jobs: - assign_one_project: - runs-on: ubuntu-latest - name: Assign to Docs SIG Project - steps: - - name: Assign NEW pull requests to Docs SIG project - uses: srggrs/assign-one-project-github-action@1.2.0 - if: github.event.action == 'opened' - with: - project: 'https://github.com/pingcap/docs-cn/projects/1' - column_name: 'PR: In Progress' diff --git a/.github/workflows/assign-to-project.yml b/.github/workflows/assign-to-project.yml new file mode 100644 index 000000000000..49e3bf43e880 --- /dev/null +++ b/.github/workflows/assign-to-project.yml @@ -0,0 +1,39 @@ +name: Assign to Project + +on: + issues: + types: [opened, labeled] + pull_request: + types: [opened, labeled] +env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + +jobs: + assign_one_project: + runs-on: ubuntu-latest + name: Assign to Project + steps: + - name: Assign NEW issues to Docs SIG project + uses: srggrs/assign-one-project-github-action@1.2.0 + if: | + github.event_name == 'issues' && + github.event.action == 'opened' + with: + project: 'https://github.com/pingcap/docs-cn/projects/1' + column_name: 'Issue: Backlog' + - name: Assign NEW pull requests to Docs SIG project + uses: srggrs/assign-one-project-github-action@1.2.0 + if: | + github.event_name == 'pull_request' && + github.event.action == 'opened' + with: + project: 'https://github.com/pingcap/docs-cn/projects/1' + column_name: 'PR: In Progress' + - name: Assign issues or PRs with translation-welcome label + uses: srggrs/assign-one-project-github-action@1.2.0 + if: | + contains(github.event.issue.labels.*.name, 'translation/welcome') || + contains(github.event.pull_request.labels.*.name, 'translation/welcome') + with: + project: 'https://github.com/pingcap/docs-cn/projects/2' + column_name: 'To do' diff --git a/.github/workflows/translation-welcome.yml b/.github/workflows/translation-welcome.yml deleted file mode 100644 index 7c717165b90c..000000000000 --- a/.github/workflows/translation-welcome.yml +++ /dev/null @@ -1,23 +0,0 @@ -name: Translation Welcome - -on: - issues: - types: [unlabeled, labeled] - pull_request: - types: [unlabeled, labeled] -env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - -jobs: - assign_one_project: - runs-on: ubuntu-latest - name: Auto Add to Project - steps: - - name: Add translation-welcome PRs/Issues to Project - uses: srggrs/assign-one-project-github-action@1.2.0 - if: | - contains(github.event.issue.labels.*.name, 'translation/welcome') || - contains(github.event.pull_request.labels.*.name, 'translation/welcome') - with: - project: 'https://github.com/pingcap/docs-cn/projects/2' - column_name: 'To do' From 226f85dcec83b318d4d21fa5bd330684f2c4ccec Mon Sep 17 00:00:00 2001 From: Lei Zhao Date: Fri, 22 May 2020 10:20:49 +0800 Subject: [PATCH 06/13] update tikv configuration about pessimistic transaction (#3178) * update tikv configuration about pessimistic transaction Signed-off-by: youjiali1995 * Update tikv-configuration-file.md Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com> * Update tikv-configuration-file.md Co-authored-by: toutdesuite Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com> Co-authored-by: toutdesuite --- tikv-configuration-file.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index f3e0d5041292..ae20d78c7280 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -1159,11 +1159,16 @@ import 相关的配置项。 ### `wait-for-lock-timeout` -+ 悲观事务在 TiKV 中等待其他事务释放锁的最长时间，单位为毫秒。若超时则会返回错误给 TiDB 并由 TiDB 重试加锁，语句最长等锁时间由 `innodb_lock_wait_timeout` 控制。 -+ 默认值：1000 -+ 最小值：1 ++ 悲观事务在 TiKV 中等待其他事务释放锁的最长时间。若超时则会返回错误给 TiDB 并由 TiDB 重试加锁，语句最长等锁时间由 `innodb_lock_wait_timeout` 控制。 ++ 默认值：1s ++ 最小值：1ms ### `wait-up-delay-duration` -+ 悲观事务释放锁时，只会唤醒等锁事务中 start ts 最小的事务，其他事务将会延迟 `wake-up-delay-duration` 毫秒之后被唤醒。 -+ 默认值：20 ++ 悲观事务释放锁时，只会唤醒等锁事务中 `start_ts` 最小的事务，其他事务将会延迟 `wake-up-delay-duration` 之后被唤醒。 ++ 默认值：20ms + +### `pipelined` + ++ 开启流水线式加悲观锁流程。开启该功能后，TiKV 在检测数据满足加锁要求后，立刻通知 TiDB 执行后面的请求，并异步写入悲观锁，从而降低大部分延迟，显著提升悲观事务的性能。但有较低概率出现悲观锁异步写入失败的情况，可能会导致悲观事务提交失败。 ++ 默认值：false From e0f89757ea27126c2d5e552e62c93c5faee25683 Mon Sep 17 00:00:00 2001 From: JaySon Date: Fri, 22 May 2020 10:31:00 +0800 Subject: [PATCH 07/13] Add TiFlash performance tuning to TOC (#3203) --- TOC.md | 1 + 1 file changed, 1 insertion(+) diff --git a/TOC.md b/TOC.md index 19eba99df3e3..f04374e910f4 100644 --- a/TOC.md +++ b/TOC.md @@ -112,6 +112,7 @@ + [软件版本](/tune-software-version.md) @张文博 + 配置 + [TiKV 调优](/tune-tikv-performance.md) @刘玮 + + [TiFlash 调优](/tiflash/tune-tiflash-performance.md) + SQL 性能调优 @崔一丁 + [SQL 性能调优概览](/sql-tuning-overview.md) + [理解 TiDB 执行计划](/query-execution-plan.md) From 133a3529ec0e0d2520987daece1d3ff84697cc81 Mon Sep 17 00:00:00 2001 From: Zwb Date: Fri, 22 May 2020 10:37:07 +0800 Subject: [PATCH 08/13] tuning: add tune-operating-system (#3157) * tuning: add tune-operating-system Signed-off-by: Wenbo Zhang * refine format and TOC * Update tune-operating-system.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> * Update tune-operating-system.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> * Update tune-operating-system.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> * Update tune-operating-system.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> * Update tune-operating-system.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> * Update tune-operating-system.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> * Update tune-operating-system.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> * Update tune-operating-system.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> Co-authored-by: yikeke Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> Co-authored-by: pingcap-github-bot --- TOC.md | 2 +- tune-operating-system.md | 117 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 118 insertions(+), 1 deletion(-) diff --git a/TOC.md b/TOC.md index f04374e910f4..2741178e6096 100644 --- a/TOC.md +++ b/TOC.md @@ -107,7 +107,7 @@ + 性能调优 + 系统调优 + [硬件](/tune-hardware-performance.md) @张文博 - + [操作系统](/tune-operating-system.md) @张文博 + + [操作系统性能参数调优](/tune-operating-system.md) @张文博 + 软件调优 + [软件版本](/tune-software-version.md) @张文博 + 配置 diff --git a/tune-operating-system.md b/tune-operating-system.md index e69de29bb2d1..9f2e66303d51 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -0,0 +1,117 @@ +--- +title: 操作系统性能参数调优 +category: reference +--- + +# 操作系统性能参数调优 + +本文档仅用于描述如何优化 Centos 7 的各个子系统。 + +> **注意：** +> +> 1. Centos 7 操作系统的默认配置适用于中等负载下运行的大多数服务。调整特定子系统的性能可能会对其他子系统产生负面影响。因此在调整系统之前，请备份所有用户数据和配置信息； +> 2. 请在测试环境下对所有修改做好充分测试后，再应用到生产环境中。 + +## 性能分析工具 + +系统调优需要根据系统性能分析的结果做指导，因此本文先列出常用的性能分析方法。 + +### 60s 分析法 + +此分析法由《性能之巅》的作者 Brendan Gregg 及其所在的 Netflix 性能工程团队公布，所用到的工具均可从发行版的官方源获取，通过分析以下清单中的输出，可定位大部分常见的性能问题。 + +1. uptime +2. dmesg | tail +3. vmstat 1 +4. mpstat -P ALL 1 +5. pidstat 1 +6. iostat -xz 1 +7. free -m +8. sar -n DEV 1 +9. sar -n TCP,ETCP 1 +10. top + +具体用法可查询相应 man 手册。 + +### perf + +Perf 是 Linux 内核提供的一个重要的性能分析工具，它涵盖硬件级别（CPU/PMU，性能监视单元）功能和软件功能（软件计数器，跟踪点）。详细用法请参考 [perf Examples](http://www.brendangregg.com/perf.html#Background)。 + +### BCC/bpftrace + +Centos 从 7.6 版本起，内核已实现对 bpf 的支持，因此可根据上述清单的结果，选取适当的工具进行深入分析。相比 perf/ftrace，bpf 提供了可编程能力，和更小的性能开销。相比 kprobe，bpf 提供了更高的安全性，更适合在生产环境上使用。关于 BCC 工具集的使用请参考 [BPF Compiler Collection (BCC)](https://github.com/iovisor/bcc/blob/master/README.md)。 + +## 性能调优 + +性能调优将根据内核子系统进行分类描述。 + +### 处理器——动态节能技术 + +cpufreq 是一个动态调整 CPU 频率的模块，可支持五种模式。为保证服务性能应选用 performance 模式，将 CPU 频率固定工作在其支持的最高运行频率上，不进行动态调节。命令为 `cpupower frequency-set --governor performance`。 + +### 处理器——中断亲和性 + +- 自动平衡：可通过 `irqbalance` 服务实现。 +- 手动平衡： + 1. 确定需要平衡中断的设备，从 Centos 7.5 开始，系统会自动为某些设备及其驱动程序配置最佳的中断关联性。不能再手动配置其亲和性。目前已知的有使用 `be2iscsi` 驱动的设备，以及 NVME 设置； + 2. 对于其他设备，可查询其芯片手册，是否支持分发中断，若不支持，则该设备的所有中断会路由到同一个 CPU 上，无法对其进行修改，若支持，则计算 `smp_affinity` 掩码并设置对应的配置文件，具体请参考[内核文档](https://www.kernel.org/doc/Documentation/IRQ-affinity.txt)。 + +### NUMA 绑核 + +为尽可能的避免跨 NUMA 访问内存，我们可以通过设置线程的 CPU 亲和性来实现。对于普通程序，可使用 numactl 命令来绑定，具体用法请查询 man 手册。对于网卡中断，请参考下文网络章节。 + +### 内存——透明大页 + +对于数据库应用，不推荐使用 THP，因为数据库往往具有稀疏而不是连续的内存访问模式，且当高阶内存碎片化比较严重时，分配 THP 页面会出现较大的延迟。伴随使能 THP 的直接内存规整功能，也会出现系统 CPU 使用率激增的现象，因此建议关闭。 + +``` sh +echo never > /sys/kernel/mm/transparent_hugepage/enabled +echo never > /sys/kernel/mm/transparent_hugepage/defrag +``` + +### 内存——虚拟内存参数 + +- `dirty_ratio` 百分比值。当脏的 page cache 总量达到系统内存总量的这一百分比后，系统将开始使用 pdflush 操作将脏的 page cache 写入磁盘。默认值为 20％，通常不需调整。对于高性能 SSD，比如 NVMe 设备来说，降低其值有利于提高内存回收时的效率。 +- `dirty_background_ratio` 百分比值。当脏的 page cache 总量达到系统内存总量的这一百分比后，系统开始在后台将脏的 page cache 写入磁盘。默认值为 10％，通常不需调整。对于高性能 SSD，比如 NVMe 设备来说，设置较低的值有利于提高内存回收时的效率。 + +### 存储及文件系统 + +内核 I/O 栈链路较长，包含了文件系统层、块设备层和驱动层。 + +#### I/O 调度器 + +I/O 调度程序确定 I/O 操作何时在存储设备上运行以及持续多长时间。也称为 I/O 升降机。对于 SSD 设备，宜设置为 noop。 + +```sh +echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler +``` + +#### 格式化参数——块大小 + +块是文件系统的工作单元。块大小决定了单个块中可以存储多少数据，因此决定了一次写入或读取的最小数据量。 + +默认块大小适用于大多数使用情况。但是，如果块大小（或多个块的大小）与通常一次读取或写入的数据量相同或稍大，则文件系统将性能更好，数据存储效率更高。小文件仍将使用整个块。文件可以分布在多个块中，但这会增加运行时开销。 + +使用 mkfs 命令格式化设备时，将块大小指定为文件系统选项的一部分。指定块大小的参数随文件系统的不同而不同。有关详细信息，请查询对应文件系统的 mkfs 手册页，比如 `man mkfs.ext4`。 + +#### 挂载参数 + +`noatime` 读取文件时，将禁用对元数据的更新。它还启用了 nodiratime 行为，该行为会在读取目录时禁用对元数据的更新。 + +### 网络 + +网络子系统由具有敏感连接的许多不同部分组成。因此，Centos 7 网络子系统旨在为大多数工作负载提供最佳性能，并自动优化其性能。因此，通常无需手动调整网络性能。 + +网络问题通常由硬件或相关设施出现问题导致的，因此在调优协议栈前，请先排除硬件问题。 + +尽管网络堆栈在很大程度上是自我优化的，但是在网络数据包处理过程中有许多要点可能会成为瓶颈并降低性能： + +- 网卡硬件缓存：正确观察硬件层面的丢包方法是使用 `ethtool -S ${NIC_DEV_NAME}` 命令观察 drops 字段。当出现丢包现象时，主要考虑是硬/软中断的处理速度跟不上网卡接收速度。若接收缓存小于最大限制时，也可尝试增加 RX 缓存来防止丢包。查询命令为：`ethtool -g ${NIC_DEV_NAME}`，修改命令为 `ethtool -G ${NIC_DEV_NAME}`。 +- 硬中断：若网卡支持 Receive-Side Scaling（RSS 也称为多网卡接收）功能，则观察 /proc/interrrputs 网卡中断，如果出现了中断不均衡的情况，请参考处理器调优章节。若不支持 RSS 或 RSS 数量远小于物理 CPU 核数，则可配置 Receive Packet Steering（RPS，可以看作 RSS 的软件实现），及 RPS 的扩展 Receive Flow Steering (RFS)。具体设置请参考[内核文档](https://www.kernel.org/doc/Documentation/networking/scaling.txt)。 +- 软中断：观察 /proc/net/softnet\_stat 监控，如果除第三列的其他列的数值在增长，则应适度调大 net.core.netdev\_budget 或 net.core.dev\_weight 值，使 softirq 可以获得更多的 CPU 时间。除此之外，也需要检查 CPU 使用情况，确定哪些任务在频繁占用 CPU，能否优化。 +- 应用的套接字接收队列：监控 `ss -nmp` 的 `Recv-q` 列，若队列已满，则应考虑增大应用程序套接字的缓存大小或使用自动调整缓存的方式。除此之外，也要考虑能否优化应用层的架构，降低读取套接字的间隔。 +- 以太网流控：若网卡和交换机支持流控功能，可通过使能此功能，给内核一些时间来处理网卡队列中的数据，来规避网卡缓存溢出的问题。对于网卡测，可通过 `ethtool -a ${NIC_DEV_NAME}` 命令检查是否支持/使能，并通过 `ethtool -A ${NIC_DEV_NAME}` 命令开启。对于交换机，请查询其手册。 +- 中断合并：过于频繁的硬件中断会降低系统性能，而过晚的硬件中断会导致丢包。对于较新的网卡支持中断合并功能，并允许驱动自动调节硬件中断数。可通过 `ethtool -c ${NIC_DEV_NAME}` 命令检查，`ethtool -C ${NIC_DEV_NAME}` 命令开启。自适应模式使网卡可以自动调节中断合并。在自适应模式下，驱动程序将检查流量模式和内核接收模式，并实时评估合并设置，以防止数据包丢失。不同品牌的网卡具有不同的功能和默认配置，具体请参考网卡手册。 +- 适配器队列：在协议栈处理之前，内核利用此队列缓存网卡接收的数据，每个 CPU 都有各自的 backlog 队列。此队列可缓存的最大 packets 数量为 netdev\_max\_backlog。观察 /proc/net/softnet\_stat 第二列，当某行的第二列持续增加，则意味着 CPU [行-1] 队列已满，数据包被丢失，可通过持续加倍 net.core.netdev\_max\_backlog 值来解决。 +- 发送队列：发送队列长度值确定在发送之前可以排队的数据包数量。默认值是 1000，对于 10Gbps 足够。但若从 `ip -s link` 的输出中观察到 TX errors 值时，可尝试加倍：`ip link set dev ${NIC_DEV_NAME} txqueuelen 2000`。 +- 驱动：网卡驱动通常也会提供调优参数，请查询设备硬件手册及其驱动文档。 From 0e18ff737eea17bc0fcee78909aba249f4132843 Mon Sep 17 00:00:00 2001 From: lidezhu <47731263+lidezhu@users.noreply.github.com> Date: Fri, 22 May 2020 11:32:07 +0800 Subject: [PATCH 09/13] add doc about tiflash command line flags (#3205) * add doc about tiflash command line flags * Small fix for format * Try fix link * Update tiflash/tiflash-command-line-flags.md Co-authored-by: Keke Yi <40977455+yikeke@users.noreply.github.com> Co-authored-by: pingcap-github-bot --- tiflash/tiflash-command-line-flags.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md index e69de29bb2d1..55673c64d6f1 100644 --- a/tiflash/tiflash-command-line-flags.md +++ b/tiflash/tiflash-command-line-flags.md @@ -0,0 +1,14 @@ +--- +title: TiFlash 命令行参数 +category: reference +--- + +# TiFlash 命令行参数 + +本文介绍了 TiFlash 的命令行启动参数。 + +## `server --config-file` + ++ 指定 TiFlash 的配置文件路径 ++ 默认："" ++ 必须指定配置文件，详细的配置项请参阅 [TiFlash 配置参数](/tiflash/tiflash-configuration.md) From 91e6555f73f5ee1fd4b471081cfc8bdff58c3b79 Mon Sep 17 00:00:00 2001 From: pepezzzz <35323945+pepezzzz@users.noreply.github.com> Date: Fri, 22 May 2020 13:02:08 +0800 Subject: [PATCH 10/13] split to DDL DML DQL DCL sections (#3215) * Add files via upload * update format * Update basic-sql-operations.md Co-authored-by: Ran --- basic-sql-operations.md | 163 +++++++++++++++++++++------------------- 1 file changed, 85 insertions(+), 78 deletions(-) diff --git a/basic-sql-operations.md b/basic-sql-operations.md index 29d8b5d06a5c..48ef149c3345 100644 --- a/basic-sql-operations.md +++ b/basic-sql-operations.md @@ -1,34 +1,34 @@ --- -title: TiDB 中的基本 SQL 操作 +title: SQL 基本操作 category: how-to aliases: ['/docs-cn/dev/how-to/get-started/explore-sql/'] --- -# TiDB 中的基本 SQL 操作 +# SQL 基本操作 成功部署 TiDB 集群之后，便可以在 TiDB 中执行 SQL 语句了。因为 TiDB 兼容 MySQL，你可以使用 MySQL 客户端连接 TiDB，并且[大多数情况下](/mysql-compatibility.md)可以直接执行 MySQL 语句。 -本文介绍 CRUD 操作等基本的 SQL 语句。完整的 SQL 语句列表，参见 [TiDB SQL 语法详解](https://pingcap.github.io/sqlgram/)。 +SQL 是一门声明性语言，它是数据库用户与数据库交互的方式。它更像是一种自然语言，好像在用英语与数据库进行对话。本文档介绍基本的 SQL 操作。完整的 SQL 语句列表，参见 [TiDB SQL 语法详解](https://pingcap.github.io/sqlgram/)。 -## 创建、查看和删除数据库 +## 分类 -使用 `CREATE DATABASE` 语句创建数据库。语法如下： +SQL 语言通常按照功能划分成以下的 4 个部分： -{{< copyable "sql" >}} +- DDL (Data Definition Language)：数据定义语言，用来定义数据库对象，包括库、表、视图和索引等。 -```sql -CREATE DATABASE db_name [options]; -``` +- DML (Data Manipulation Language)：数据操作语言，用来操作和业务相关的记录。 -例如，要创建一个名为 `samp_db` 的数据库，可使用以下语句： +- DQL (Data Query Language)：数据查询语言，用来查询经过条件筛选的记录。 -{{< copyable "sql" >}} +- DCL (Data Control Language)：数据控制语言，用来定义访问权限和安全级别。 -```sql -CREATE DATABASE IF NOT EXISTS samp_db; -``` +常用的 DDL 功能是对象（如表、索引等）的创建、属性修改和删除，对应的命令分别是 CREATE、ALTER 和 DROP。 + +## 查看、创建和删除数据库 + +TiDB 语境中的 Database 或者说数据库，可以认为是表和索引等对象的集合。 -使用 `SHOW DATABASES` 语句查看数据库： +使用 `SHOW DATABASES` 语句查看系统中数据库列表： {{< copyable "sql" >}} @@ -36,104 +36,102 @@ CREATE DATABASE IF NOT EXISTS samp_db; SHOW DATABASES; ``` -使用 `DROP DATABASE` 语句删除数据库，例如： +使用名为 `mysql` 的数据库： {{< copyable "sql" >}} ```sql -DROP DATABASE samp_db; +use mysql; ``` -## 创建、查看和删除表 - -使用 `CREATE TABLE` 语句创建表。语法如下： +使用 `SHOW TABLES` 语句查看数据库中的所有表。例如： {{< copyable "sql" >}} ```sql -CREATE TABLE table_name column_name data_type constraint; +SHOW TABLES FROM mysql; ``` -例如： +使用 `CREATE DATABASE` 语句创建数据库。语法如下： {{< copyable "sql" >}} ```sql -CREATE TABLE person ( - number INT(11), - name VARCHAR(255), - birthday DATE - ); +CREATE DATABASE db_name [options]; ``` -如果表已存在，添加 `IF NOT EXISTS` 可防止发生错误： +例如，要创建一个名为 `samp_db` 的数据库，可使用以下语句： {{< copyable "sql" >}} ```sql -CREATE TABLE IF NOT EXISTS person ( - number INT(11), - name VARCHAR(255), - birthday DATE -); +CREATE DATABASE IF NOT EXISTS samp_db; ``` -使用 `SHOW CREATE` 语句查看建表语句。例如： +添加 `IF NOT EXISTS` 可防止发生错误。 + +使用 `DROP DATABASE` 语句删除数据库。例如： {{< copyable "sql" >}} ```sql -SHOW CREATE table person; +DROP DATABASE samp_db; ``` -使用 `SHOW FULL COLUMNS` 语句查看表的列。 例如： +## 创建、查看和删除表 + +使用 `CREATE TABLE` 语句创建表。语法如下： {{< copyable "sql" >}} ```sql -SHOW FULL COLUMNS FROM person; +CREATE TABLE table_name column_name data_type constraint; ``` -使用 `DROP TABLE` 语句删除表。例如： +例如，要创建一个名为 `person` 的表，包括编号、名字、生日等字段，可使用以下语句： {{< copyable "sql" >}} ```sql -DROP TABLE person; +CREATE TABLE person ( + id INT(11), + name VARCHAR(255), + birthday DATE + ); ``` -或者 +使用 `SHOW CREATE` 语句查看建表语句，即 DDL。例如： {{< copyable "sql" >}} ```sql -DROP TABLE IF EXISTS person; +SHOW CREATE table person; ``` -使用 `SHOW TABLES` 语句查看数据库中的所有表。例如： +使用 `DROP TABLE` 语句删除表。例如： {{< copyable "sql" >}} ```sql -SHOW TABLES FROM samp_db; +DROP TABLE person; ``` ## 创建、查看和删除索引 -对于值不唯一的列，可使用 `CREATE INDEX` 或 `ALTER TABLE` 语句。例如： +索引通常用于加速索引列上的查询。对于值不唯一的列，可使用 `CREATE INDEX` 或 `ALTER TABLE` 语句创建普通索引。例如： {{< copyable "sql" >}} ```sql -CREATE INDEX person_num ON person (number); +CREATE INDEX person_id ON person (id); ``` -或者 +或者： {{< copyable "sql" >}} ```sql -ALTER TABLE person ADD INDEX person_num (number); +ALTER TABLE person ADD INDEX person_id (id); ``` 对于值唯一的列，可以创建唯一索引。例如： @@ -141,15 +139,15 @@ ALTER TABLE person ADD INDEX person_num (number); {{< copyable "sql" >}} ```sql -CREATE UNIQUE INDEX person_num ON person (number); +CREATE UNIQUE INDEX person_unique_id ON person (id); ``` -或者 +或者： {{< copyable "sql" >}} ```sql -ALTER TABLE person ADD UNIQUE person_num (number); +ALTER TABLE person ADD UNIQUE person_unique_id (id); ``` 使用 `SHOW INDEX` 语句查看表内所有索引： @@ -165,18 +163,22 @@ SHOW INDEX from person; {{< copyable "sql" >}} ```sql -DROP INDEX person_num ON person; +DROP INDEX person_id ON person; ``` {{< copyable "sql" >}} ```sql -ALTER TABLE person DROP INDEX person_num; +ALTER TABLE person DROP INDEX person_unique_id; ``` -## 增删改查数据 +注意：DDL 操作不是事务，在执行 DDL 时，不需要对应 COMMIT 语句。 + +常用的 DML 功能是对表记录的新增、修改和删除，对应的命令分别是 INSERT、UPDATE 和 DELETE。 -使用 `INSERT` 语句向表内插入数据。例如： +## 记录的增删改 + +使用 `INSERT` 语句向表内插入表记录。例如： {{< copyable "sql" >}} @@ -184,61 +186,66 @@ ALTER TABLE person DROP INDEX person_num; INSERT INTO person VALUES("1","tom","20170912"); ``` -使用 `SELECT` 语句检索表内数据。例如： +使用 `INSERT` 语句向表内插入包含部分字段数据的表记录。例如： {{< copyable "sql" >}} ```sql -SELECT * FROM person; +INSERT INTO person(id,name) VALUES("2","bob"); ``` -``` -+--------+------+------------+ -| number | name | birthday | -+--------+------+------------+ -| 1 | tom | 2017-09-12 | -+--------+------+------------+ +使用 `UPDATE` 语句向表内修改表记录的部分字段数据。例如： + +{{< copyable "sql" >}} + +```sql +UPDATE person SET birthday="20180808" WHERE id=2; ``` -使用 `UPDATE` 语句修改表内数据。例如： +使用 `DELETE` 语句向表内删除部分表记录。例如： {{< copyable "sql" >}} ```sql -UPDATE person SET birthday='20171010' WHERE name='tom'; +DELETE FROM person WHERE id=2; ``` +注意：UPDATE 和 DELETE 操作如果不带 WHERE 过滤条件是对全表进行操作。 + +DQL 数据查询语言是从一个表或多个表中检索出想要的数据行，通常是业务开发的核心内容。 + +## 查询数据 + +使用 `SELECT` 语句检索表内数据。例如： + {{< copyable "sql" >}} ```sql SELECT * FROM person; ``` -``` -+--------+------+------------+ -| number | name | birthday | -+--------+------+------------+ -| 1 | tom | 2017-10-10 | -+--------+------+------------+ -``` - -使用 `DELETE` 语句删除表内数据： +在 SELECT 后面加上要查询的列名。例如： {{< copyable "sql" >}} ```sql -DELETE FROM person WHERE number=1; +SELECT name FROM person; ++------+ +| name | ++------+ +| tom | ++------+ ``` +使用 WHERE 子句，对所有记录进行是否符合条件的筛选后再返回。例如： + {{< copyable "sql" >}} ```sql -SELECT * FROM person; +SELECT * FROM person where id<5; ``` -``` -Empty set (0.00 sec) -``` +常用的 DCL 功能是创建或删除用户，和对用户权限的管理。 ## 创建、授权和删除用户 From 7ec0e1aa7c7246a4a397ecd8b8ac48cae82ce256 Mon Sep 17 00:00:00 2001 From: ShuNing Date: Fri, 22 May 2020 13:17:00 +0800 Subject: [PATCH 11/13] Update command line flags for tikv configruation (#3155) --- command-line-flags-for-tikv-configuration.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index 1bf9799400f7..f9d584f5007d 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -24,6 +24,13 @@ TiKV 的命令行参数支持一些可读性好的单位转换。 + 在某些情况下，譬如 docker，或者 NAT 网络环境，客户端并不能通过 TiKV 自己监听的地址来访问到 TiKV，这时候，你就可以设置 advertise addr 来让 客户端访问 + 例如，docker 内部 IP 地址为 172.17.0.1，而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 -p 20160:20160，那么可以设置为 \-\-advertise-addr="192.168.100.113:20160"，客户端可以通过 192.168.100.113:20160 来找到这个服务 +## `--status-addr` + ++ TiKV 服务状态监听端口 ++ 默认："20180" ++ Prometheus 统计可以通过 `http://host:status_port/metrics` 访问 ++ Profile 数据可以通过 `http://host:status_port/debug/pprof/profile` 访问 + ## `-C, --config` + 配置文件 From 8109c570d67f9d7783b1e854bdc6cf563a4a8de4 Mon Sep 17 00:00:00 2001 From: tangenta Date: Fri, 22 May 2020 15:10:01 +0800 Subject: [PATCH 12/13] update mysql-compatibility.md & add auto-increment.md (#3163) --- auto-increment.md | 202 +++++++++++++++++++++++++++++++++++++++++ auto-random.md | 1 + mysql-compatibility.md | 100 +++++--------------- 3 files changed, 226 insertions(+), 77 deletions(-) diff --git a/auto-increment.md b/auto-increment.md index e69de29bb2d1..391914881157 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -0,0 +1,202 @@ +--- +title: AUTO_INCREMENT +category: reference +summary: 介绍 TiDB 的 `AUTO_INCREMENT` 列属性。 +--- + +# AUTO_INCREMENT + +本文介绍列属性 `AUTO_INCREMENT` 的基本概念、实现原理、自增相关的特性，以及使用限制。 + +## 基本概念 + +`AUTO_INCREMENT` 是用于自动填充缺省列值的列属性。当 `INSERT` 语句没有指定 `AUTO_INCREMENT` 列的具体值时，系统会自动地为该列分配一个值。该值满足唯一性，以及**特殊情况下**的递增性和连续性。使用示例如下： + +{{< copyable "sql" >}} + +```sql +create table t(id int primary key AUTO_INCREMENT, c int); +``` + +{{< copyable "sql" >}} + +```sql +insert into t(c) values (1); +insert into t(c) values (2); +insert into t(c) values (3), (4), (5); +``` + +```sql +mysql> select * from t; ++----+---+ +| id | c | ++----+---+ +| 1 | 1 | +| 2 | 2 | +| 3 | 3 | +| 4 | 4 | +| 5 | 5 | ++----+---+ +5 rows in set (0.01 sec) +``` + +此外，`AUTO_INCREMENT` 还支持显式指定列值的插入语句，此时 TiDB 会保存显式指定的值： + +{{< copyable "sql" >}} + +```sql +insert into t(id, c) values (6, 6); +``` + +```sql +mysql> select * from t; ++----+---+ +| id | c | ++----+---+ +| 1 | 1 | +| 2 | 2 | +| 3 | 3 | +| 4 | 4 | +| 5 | 5 | +| 6 | 6 | ++----+---+ +6 rows in set (0.01 sec) +``` + +以上用法和 MySQL 的 `AUTO_INCREMENT` 用法一致。但在隐式分配的具体值方面，TiDB 和 MySQL 之间具有较为显著的差异。 + +## 实现原理 + +TiDB 实现 `AUTO_INCREMENT` 隐式分配的原理是，对于每一个自增列，都使用一个全局可见的键值对用于记录当前已分配的最大 ID。由于分布式环境下的节点通信存在一定开销，为了避免写请求放大的问题，每个 TiDB 节点在分配 ID 时，都申请一段 ID 作为缓存，用完之后再去取下一段，而不是每次分配都向存储节点申请。例如，对于以下新建的表： + +```sql +create table t(id int unique key AUTO_INCREMENT, c int); +``` + +假设集群中有两个 TiDB 实例 A 和 B，如果向 A 和 B 分别对 `t` 执行一条插入语句： + +```sql +insert into t (c) values (1) +``` + +实例 A 可能会缓存 `[1,30000]` 的自增 ID，而实例 B 则可能缓存 `[30001,60000]` 的自增 ID。各自实例缓存的 ID 将随着执行将来的插入语句被作为缺省值，顺序地填充到 `AUTO_INCREMENT` 列中。 + +## 基本特性 + +### 唯一性保证 + +> **警告：** +> +> 在集群中有多个 TiDB 实例时，如果表结构中有自增 ID，建议不要混用显式插入和隐式分配（即自增列的缺省值和自定义值），否则可能会破坏隐式分配值的唯一性。 + +例如在上述示例中，依次执行如下操作： + +1. 客户端向实例 B 插入一条将 `id` 设置为 `2` 的语句 `insert into t values (2, 1)`，并执行成功。 +2. 客户端向实例 A 发送 `Insert` 语句 `insert into t (c) (1)`，这条语句中没有指定 `id` 的值，所以会由 A 分配。当前 A 缓存了 `[1, 30000]` 这段 ID，可能会分配 `2` 为自增 ID 的值，并把本地计数器加 `1`。而此时数据库中已经存在 `id` 为 `2` 的数据，最终返回 `Duplicated Error` 错误。 + +### 递增性保证 + +`AUTO_INCREMENT` 列隐式分配值的递增性只能在含有单个 TiDB 实例的集群中得到保证：即对于同一个自增列，先分配的值小于后分配的值；而在含有多个 TiDB 实例的集群中，无法保证自增列的递增性。 + +例如，对于上述例子，如果先向实例 B 执行一条插入语句，再向实例 A 执行一条插入语句。根据缓存自增 ID 的性质，自增列隐式分配的值可能分别是 `30002` 和 `2`。因此从时间上看，不满足递增性。 + +### 连续性保证 + +在含有多个 TiDB 实例的集群中，`AUTO_INCREMENT` 分配值的连续性**只能**在 batch insert 语句中得到保证。 + +例如，对以下表执行以下语句： + +```sql +create table t (a int primary key AUTO_INCREMENT) +``` + +```sql +insert into t values (), (), (), () +``` + +即使存在正在执行并发写入的其他 TiDB 实例，或者当前实例剩余的缓存 ID 数量不够，都不会影响分配值的连续性。 + +### `_tidb_rowid` 的关联性 + +> **注意：** +> +> 在没有指定整数类型主键的情况下 TiDB 会使用 `_tidb_rowid` 来标识行，该数值的分配会和自增列（如果存在的话）共用一个分配器，其中缓存的大小可能会被自增列和 `_tidb_rowid` 共同消耗。因此会有以下的示例情况： + +```sql +mysql> create table t(id int unique key AUTO_INCREMENT); +Query OK, 0 rows affected (0.05 sec) + +mysql> insert into t values (),(),(); +Query OK, 3 rows affected (0.00 sec) +Records: 3 Duplicates: 0 Warnings: 0 + +mysql> select _tidb_rowid, id from t; ++-------------+------+ +| _tidb_rowid | id | ++-------------+------+ +| 4 | 1 | +| 5 | 2 | +| 6 | 3 | ++-------------+------+ +3 rows in set (0.01 sec) +``` + +### 缓存大小控制 + +TiDB 自增 ID 的缓存大小在早期版本中是对用户透明的。从 v3.1.2、v3.0.14 和 v4.0.rc-2 版本开始，TiDB 引入了 `AUTO_ID_CACHE` 表选项来允许用户自主设置自增 ID 分配缓存的大小。例如： + +```sql +mysql> create table t(a int auto_increment key) AUTO_ID_CACHE 100; +Query OK, 0 rows affected (0.02 sec) + +mysql> insert into t values(); +Query OK, 1 row affected (0.00 sec) +Records: 1 Duplicates: 0 Warnings: 0 + +mysql> select * from t; ++---+ +| a | ++---+ +| 1 | ++---+ +1 row in set (0.01 sec) +``` + +此时如果将该列的自增缓存无效化，重新进行隐式分配： + +```sql +mysql> delete from t; +Query OK, 1 row affected (0.01 sec) + +mysql> rename table t to t1; +Query OK, 0 rows affected (0.01 sec) + +mysql> insert into t1 values() +Query OK, 1 row affected (0.00 sec) + +mysql> select * from t; ++-----+ +| a | ++-----+ +| 101 | ++-----+ +1 row in set (0.00 sec) +``` + +可以看到再一次分配的值为 `101`，说明该表的自增 ID 分配缓存的大小为 `100`。 + +此外如果在批量插入的 `INSERT` 语句中所需连续 ID 长度超过 `AUTO_ID_CACHE` 的长度时，TiDB 会适当调大缓存以便能够保证该语句的正常插入。 + +### 自增步长和偏移量设置 + +从 v3.0.9 和 v4.0.rc-1 开始，和 MySQL 的行为类似，自增列隐式分配的值遵循 session 变量 `@@auto_increment_increment` 和 `@@auto_increment_offset` 的控制，其中自增列隐式分配的值 (ID) 将满足式子 `(ID - auto_increment_offset) % auto_increment_increment == 0`。 + +## 使用限制 + +目前在 TiDB 中使用 `AUTO_INCREMENT` 有以下限制： + +- 必须定义在主键或者唯一索引的列上。 +- 只能定义在类型为整数、`FLOAT` 或 `DOUBLE` 的列上。 +- 不支持与列的默认值 `DEFAULT` 同时指定在同一列上。 +- 不支持使用 `ALTER TABLE` 来添加 `AUTO_INCREMENT` 属性。 +- 支持使用 `ALTER TABLE` 来移除 `AUTO_INCREMENT` 属性。但从 TiDB 2.1.18 和 3.0.4 版本开始，TiDB 通过 session 变量 `@@tidb_allow_remove_auto_inc` 控制是否允许通过 `ALTER TABLE MODIFY` 或 `ALTER TABLE CHANGE` 来移除列的 `AUTO_INCREMENT` 属性，默认是不允许移除。 diff --git a/auto-random.md b/auto-random.md index 3c7342eb1427..94c7b1b5419f 100644 --- a/auto-random.md +++ b/auto-random.md @@ -1,6 +1,7 @@ --- title: AUTO_RANDOM category: reference +summary: 本文介绍了 TiDB 的 `AUTO_RANDOM` 列属性。 aliases: ['/docs-cn/dev/reference/sql/attributes/auto-random/'] --- diff --git a/mysql-compatibility.md b/mysql-compatibility.md index 6b8d33079a59..cba05121e01c 100644 --- a/mysql-compatibility.md +++ b/mysql-compatibility.md @@ -1,5 +1,6 @@ --- title: 与 MySQL 兼容性对比 +summary: 本文对 TiDB 和 MySQL 二者之间从语法和功能特性上做出详细的对比。 category: reference aliases: ['/docs-cn/dev/reference/mysql-compatibility/'] --- @@ -42,57 +43,13 @@ TiDB 支持 MySQL 传输协议及其绝大多数的语法。这意味着您现 ### 自增 ID -TiDB 中，自增列只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配 ID 的方式，所以如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。 - -在集群中有多个 tidb-server 实例时，如果表结构中有自增 ID，建议不要混用缺省值和自定义值，否则在如下情况下会遇到问题。 - -假设有这样一个带有自增 ID 的表： - -{{< copyable "sql" >}} - -```sql -create table t(id int unique key AUTO_INCREMENT, c int); -``` - -TiDB 实现自增 ID 的原理是每个 tidb-server 实例缓存一段 ID 值用于分配（目前会缓存 30000 个 ID），用完这段值再去取下一段。 - -假设集群中有两个 tidb-server 实例 A 和 B（A 缓存 [1,30000] 的自增 ID，B 缓存 [30001,60000] 的自增 ID），依次执行如下操作： - -1. 客户端向 B 插入一条将 `id` 设置为 1 的语句 `insert into t values (1, 1)`，并执行成功。 -2. 客户端向 A 发送 Insert 语句 `insert into t (c) (1)`，这条语句中没有指定 `id` 的值，所以会由 A 分配，当前 A 缓存了 [1, 30000] 这段 ID，所以会分配 1 为自增 ID 的值，并把本地计数器加 1。而此时数据库中已经存在 `id` 为 1 的数据，最终返回 `Duplicated Error` 错误。 - -另外，从 TiDB 2.1.18 和 3.0.4 版本开始，TiDB 将通过系统变量 `@@tidb_allow_remove_auto_inc` 控制是否允许通过 `alter table modify` 或 `alter table change` 来移除列的 `AUTO_INCREMENT` 属性，默认是不允许移除。 - -> **注意：** -> -> 在没有指定主键的情况下 TiDB 会使用 `_tidb_rowid` 来标识行，该数值的分配会和自增列（如果存在的话）共用一个分配器。如果指定了自增列为主键，则 TiDB 会用该列来标识行。因此会有以下的示例情况： - -```sql -mysql> create table t(id int unique key AUTO_INCREMENT); -Query OK, 0 rows affected (0.05 sec) - -mysql> insert into t values(),(),(); -Query OK, 3 rows affected (0.00 sec) -Records: 3 Duplicates: 0 Warnings: 0 - -mysql> select _tidb_rowid, id from t; -+-------------+------+ -| _tidb_rowid | id | -+-------------+------+ -| 4 | 1 | -| 5 | 2 | -| 6 | 3 | -+-------------+------+ -3 rows in set (0.01 sec) -``` - -TiDB 自增 ID 的缓存大小在早期版本中是对用户透明的。从 v3.1.2、v3.0.14 和 v4.0.rc.2 版本开始，TiDB 引入了 `AUTO_ID_CACHE` 表选项来允许用户自主设置自增 ID 分配缓存的大小。其中缓存大小可能会被自增列和 `_tidb_rowid` 共同消耗。此外如果在 `INSERT` 语句中所需连续 ID 长度超过 `AUTO_ID_CACHE` 的长度时，TiDB 会适当调大缓存以便能够保证该语句的正常插入。 +TiDB 中，对于自增列隐式分配的值，只保证单节点的自增和全局节点的唯一，不保证连续性。TiDB 目前采用批量分配 ID 的方式，如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。此外，不恰当地混用自定义值和缺省值可能会破坏数据唯一性。详情参见 [AUTO_INCREMENT](/auto-increment.md)。 ### Performance schema Performance schema 表在 TiDB 中返回结果为空。TiDB 使用 [Prometheus 和 Grafana](/monitor-a-tidb-cluster.md) 来监测性能指标。 -从 TiDB 3.0.4 版本开始，TiDB 支持 `events_statements_summary_by_digest`，参见 [Statement Summary Table](/statement-summary-tables.md)。 +针对 SQL 性能相关的问题，从 TiDB 4.0.0-rc.1 版本开始，TiDB 支持 `statements_summary`（和 MySQL 中的 `events_statements_summary_by_digest` 功能相似），用于监控和统计 SQL 语句。参见 [Statement Summary Table](/statement-summary-tables.md)。 ### 查询计划 @@ -104,34 +61,23 @@ TiDB 支持常用的 MySQL 内建函数，但是不是所有的函数都已经 ### DDL -在 TiDB 中，运行的 DDL 操作不会影响对表的读取或写入。但是，目前 DDL 变更有如下一些限制： - -+ Add Index - - 不支持同时创建多个索引 - - 其他类型的 Index Type (HASH/BTREE/RTREE) 只有语法支持，功能不支持 -+ Add Column - - 不支持将新创建的列设为主键或唯一索引，也不支持将此列设成 AUTO_INCREMENT 属性 -+ Drop Column: 不支持删除主键列或索引列 -+ Change/Modify Column - - 不支持有损变更，比如从 `BIGINT` 变为 `INTEGER`，或者从 `VARCHAR(255)` 变为 `VARCHAR(10)` - - 不支持修改 `DECIMAL` 类型的精度 - - 不支持更改 `UNSIGNED` 属性 - - 只支持将 `CHARACTER SET` 属性从 `utf8` 更改为 `utf8mb4` -+ `LOCK [=] {DEFAULT|NONE|SHARED|EXCLUSIVE}`: TiDB 支持的语法，但是在 TiDB 中不会生效。所有支持的 DDL 变更都不会锁表。 -+ `ALGORITHM [=] {DEFAULT|INSTANT|INPLACE|COPY}`: TiDB 完全支持 `ALGORITHM=INSTANT` 和 `ALGORITHM=INPLACE` 语法，但运行过程与 MySQL 有所不同，因为 MySQL 中的一些 `INPLACE` 操作实际上是 TiDB 中的 `INSTANT` 操作。`ALGORITHM=COPY` 语法在 TiDB 中不会生效，会返回警告信息。 -+ 单个 `ALTER TABLE` 语句中无法完成多个操作。例如，不能用一个语句来添加多个列或多个索引。 -+ Table Option 不支持以下语法 - - `WITH/WITHOUT VALIDATION` - - `SECONDARY_LOAD/SECONDARY_UNLOAD` - - `CHECK/DROP CHECK` - - `STATS_AUTO_RECALC/STATS_SAMPLE_PAGES` - - `SECONDARY_ENGINE` - - `ENCRYPTION` -+ Table Partition 不支持以下语法 - - `PARTITION BY LIST` - - `PARTITION BY KEY` - - `SUBPARTITION` - - `{CHECK|EXCHANGE|TRUNCATE|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD|REORGANIZE} PARTITION` +在 TiDB 中，运行的 DDL 操作不会影响对表的读取或写入。但是，目前 DDL 以下变更和 MySQL 的 DDL 变更有所区别： + +| 语句类型 | 描述 | 错误信息示例 | +| :------ | :---- | :------ | +| Alter Table | 不支持在单个 alter 语句中指定多个 alter 选项 | `Unsupported multi schema change` | +| Table Option | 表选项除了 `AUTO_INCREMENT`、`CHARACTER SET`、`COLLATE`、`COMMENT` 以外，其他所有的选项都会被忽略 | N/A | +| Add Column | 不支持将新列设为主键、唯一索引或自增 | `unsupported add column '%s' constraint PRIMARY/UNIQUE/AUTO_INCREMENT KEY` | +| Change Column/Modify Column | 不支持列类型有损变更，例如 `BIGINT` -> `INT`，或者 `VARCHAR(255)` -> `VARCHAR(10)` | `length %d is less than origin %d` | +| Change Column/Modify Column | 不支持修改 `DECIMAL` 类型的精度 | `can't change decimal column precision` | +| Change Column/Modify Column | 不支持更改 `UNSIGNED` 属性 | `can't change unsigned integer to signed or vice versa` | +| Drop Column | 不支持删除主键列或索引列 | `Unsupported drop integer primary key/column a with index covered` | +| Add Index | 仅支持 `VISIBLE`/`INVISIBLE` 索引选项，其他索引选项将被忽略 | N/A | +| Drop Primary Key | 仅支持删除建表时启用了 `alter-primary-key` 配置项的表的主键 | `Unsupported drop primary key when alter-primary-key is false` | +| Order By | 所有列排序选项将被忽略 | N/A | +| Lock | 所有锁选项将被忽略，TiDB 的 DDL 变更都不会锁表 | N/A | +| Algorithm | 运行过程与 MySQL 有所不同，MySQL 中的一些 `INPLACE` 操作实际上是 TiDB 中的 `INSTANT` 操作；`ALGORITHM=COPY` 语法在 TiDB 中不会生效，会返回警告信息。| N/A | +| Partition | 分区类型仅支持 Hash/Range；分区管理操作仅支持 Add/Drop/Truncate/Coalese；其他分区操作、分区类型和子分区语句会被忽略 | `Warning: Unsupported partition type, treat as normal table` | ### `ANALYZE TABLE` @@ -158,7 +104,7 @@ Query OK, 0 rows affected (0.14 sec) {{< copyable "sql" >}} ```sql -SHOW CREATE TABLE t1; +SHOW CREATE TABLE t1\G; ``` ``` @@ -180,7 +126,7 @@ TiDB 支持 MySQL 5.7 中 **绝大多数的 SQL 模式**，以下几种模式除 - TiDB 中的 `ONLY_FULL_GROUP_BY` 与 MySQL 5.7 相比有细微的[语义差别](/functions-and-operators/aggregate-group-by-functions.md#与-mysql-的区别)，此问题日后将予以解决。 - `NO_DIR_IN_CREATE` 和 `NO_ENGINE_SUBSTITUTION` 这两种 SQL 模式用于解决兼容问题，但并不适用于 TiDB。 -### 默认设置的区别 +### 默认设置 + 默认字符集与 MySQL 不同： + TiDB 中为 `utf8mb4` @@ -196,7 +142,7 @@ TiDB 支持 MySQL 5.7 中 **绝大多数的 SQL 模式**，以下几种模式除 + 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 中默认设置： + MySQL 5.7 的默认 SQL mode 与 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` + + MySQL 8.0 中相对 5.7 少了 `NO_AUTO_CREATE_USER`， 即 `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` 的默认值不同： + TiDB 中该值默认为 2，并且目前 TiDB 只支持设置该值为 2 + MySQL 中默认设置： From 832cc1f3f125218da8e1330792a55237fd9f3a0f Mon Sep 17 00:00:00 2001 From: lawyerphx Date: Fri, 22 May 2020 16:42:57 +0800 Subject: [PATCH 13/13] perf-tuning: Add document for column prune (#3190) --- column-pruning.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/column-pruning.md b/column-pruning.md index 61250864ad89..e3db40df00e0 100644 --- a/column-pruning.md +++ b/column-pruning.md @@ -3,4 +3,18 @@ title: 列裁剪 category: performance --- -# 列裁剪 \ No newline at end of file +# 列裁剪 + +列裁剪的基本思想在于：对于算子中实际用不上的列，优化器在优化的过程中没有必要保留它们。 对这些列的删除会减少 I/O 资源占用，并为后续的优化带来便利。下面给出一个列重复的例子： + +假设表 t 里面有 a b c d 四列，执行如下语句： + +{{< copyable "sql" >}} + +```sql +select a from t where b > 5 +``` + +在该查询的过程中，t 表实际上只有 a, b 两列会被用到，而 c, d 的数据则显得多余。对应到该语句的查询计划，Selection 算子会用到 b 列，下面接着的 DataSource 算子会用到 a, b 两列，而剩下 c, d 两列则都可以裁剪掉，DataSource 算子在读数据时不需要将它们读进来。 + +出于上述考量，TiDB 会在逻辑优化阶段进行自上而下的扫描，裁剪不需要的列，减少资源浪费。该扫描过程称作 “列裁剪”，对应逻辑优化规则中的 `columnPruner`。如果要关闭这个规则，可以在参照[优化规则及表达式下推的黑名单](/blacklist-control-plan.md)中的关闭方法。