Merge pull request #1834 from TomShawn/update-all-anchor-links

*: update anchor links to github style
pingcap · Sep 17, 2019 · 439bb84 · 439bb84
2 parents 522963e + d33372c
commit 439bb84
Show file tree

Hide file tree

Showing 85 changed files with 161 additions and 161 deletions.
diff --git a/dev/TOC.md b/dev/TOC.md
@@ -89,7 +89,7 @@
         - [使用限制](/dev/reference/tools/data-migration/overview.md#使用限制)
       + 核心特性
         - [Table Routing](/dev/reference/tools/data-migration/features/overview.md#table-routing)
-        - [Black & White Lists](/dev/reference/tools/data-migration/features/overview.md#black-white-table-lists)
+        - [Black & White Lists](/dev/reference/tools/data-migration/features/overview.md#black--white-table-lists)
         - [Binlog Event Filter](/dev/reference/tools/data-migration/features/overview.md#binlog-event-filter)
         - [Column Mapping](/dev/reference/tools/data-migration/features/overview.md#column-mapping)
         - [同步延迟监控](/dev/reference/tools/data-migration/features/overview.md#同步延迟监控)

diff --git a/dev/faq/tidb.md b/dev/faq/tidb.md
@@ -111,7 +111,7 @@ TiDB 作为分布式数据库，在 TiDB 中修改用户密码建议使用 `set
 
 #### 1.1.22 TiDB 中，为什么出现后插入数据的自增 ID 反而小？
 
-TiDB 的自增 ID (`AUTO_INCREMENT`) 只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配的方式，所以如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。当多个线程并发往不同的 tidb-server 插入数据的时候，有可能会出现后插入的数据自增 ID 小的情况。此外，TiDB允许给整型类型的字段指定 AUTO_INCREMENT，且一个表只允许一个属性为 `AUTO_INCREMENT` 的字段。详情可参考[CREATE TABLE 语法](/dev/reference/mysql-compatibility.md#auto-increment-id)。
+TiDB 的自增 ID (`AUTO_INCREMENT`) 只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配的方式，所以如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。当多个线程并发往不同的 tidb-server 插入数据的时候，有可能会出现后插入的数据自增 ID 小的情况。此外，TiDB允许给整型类型的字段指定 AUTO_INCREMENT，且一个表只允许一个属性为 `AUTO_INCREMENT` 的字段。详情可参考[CREATE TABLE 语法](/dev/reference/mysql-compatibility.md#自增-id)。
 
 #### 1.1.23 sql_mode 默认除了通过命令 set 修改，配置文件怎么修改？
 
@@ -362,7 +362,7 @@ Binary 不是我们建议的安装方式，对升级支持也不友好，建议
 
 #### 3.1.4 TiDB (TiKV) 有哪些数据目录？
 
-默认在 ${[data-dir](/dev/reference/configuration/tikv-server/configuration/#data-dir}/data/ 目录下，其中包括 backup、db、raft、snap 四个目录，分别存储备份、数据、raft 数据及镜像数据。
+默认在 [`--data-dir`](/dev/reference/configuration/tikv-server/configuration.md#--data-dir) 目录下，其中包括 backup、db、raft、snap 四个目录，分别存储备份、数据、raft 数据及镜像数据。
 
 #### 3.1.5 TiDB 有哪些系统表？
 
@@ -922,7 +922,7 @@ ID 没什么规律，只要是唯一就行，不过生成的时候，是有一
 
 #### 6.1.2 如何打散热点
 
-TiDB 中以 Region 分片来管理数据库，通常来讲，TiDB 的热点指的是 Region 的读写访问热点。而 TiDB 中对于 PK 非整数或没有 PK 的表，可以通过设置 `SHARD_ROW_ID_BITS` 来适度分解 Region 分片，以达到打散 Region 热点的效果。详情可参考官网 [TiDB 专用系统变量和语法](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#shard-row-id-bits)中 `SHARD_ROW_ID_BITS` 的介绍。
+TiDB 中以 Region 分片来管理数据库，通常来讲，TiDB 的热点指的是 Region 的读写访问热点。而 TiDB 中对于 PK 非整数或没有 PK 的表，可以通过设置 `SHARD_ROW_ID_BITS` 来适度分解 Region 分片，以达到打散 Region 热点的效果。详情可参考官网 [TiDB 专用系统变量和语法](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#shard_row_id_bits)中 `SHARD_ROW_ID_BITS` 的介绍。
 
 ### 6.2 TiKV
 

diff --git a/dev/how-to/deploy/orchestrated/offline-ansible.md b/dev/how-to/deploy/orchestrated/offline-ansible.md
@@ -39,7 +39,7 @@ category: how-to
 
 ## 在中控机上创建 tidb 用户，并生成 ssh key
 
-参考[在中控机上创建 tidb 用户，并生成 ssh key](/dev/how-to/deploy/orchestrated/ansible.md#在中控机上创建-tidb-用户-并生成-ssh-key) 即可。
+参考[在中控机上创建 tidb 用户，并生成 ssh key](/dev/how-to/deploy/orchestrated/ansible.md#在中控机上创建-tidb-用户并生成-ssh-key) 即可。
 
 ## 在中控机器上离线安装 Ansible 及其依赖
 
@@ -136,7 +136,7 @@ category: how-to
 
 ## 分配机器资源，编辑 inventory.ini 文件
 
-参考[分配机器资源，编辑 inventory.ini 文件](/dev/how-to/deploy/orchestrated/ansible.md#分配机器资源-编辑-inventory-ini-文件)即可。
+参考[分配机器资源，编辑 inventory.ini 文件](/dev/how-to/deploy/orchestrated/ansible.md#分配机器资源编辑-inventoryini-文件)即可。
 
 ## 部署任务
 

diff --git a/dev/how-to/deploy/tidb-binlog.md b/dev/how-to/deploy/tidb-binlog.md
@@ -534,7 +534,7 @@ Drainer="192.168.0.13"
 
         > **注意：**
         >
-        > 如果下游为 MySQL/TiDB，为了保证数据的完整性，在 Drainer 初次启动前需要获取 `initial-commit-ts` 的值，并进行全量数据的备份与恢复。详细信息参见[部署 Drainer](#第-3-步-部署-drainer)。
+        > 如果下游为 MySQL/TiDB，为了保证数据的完整性，在 Drainer 初次启动前需要获取 `initial-commit-ts` 的值，并进行全量数据的备份与恢复。详细信息参见[部署 Drainer](#第-3-步部署-drainer)。
 
         初次启动时使用参数 `initial-commit-ts`， 命令如下：
 

diff --git a/dev/how-to/troubleshoot/data-migration.md b/dev/how-to/troubleshoot/data-migration.md
@@ -51,7 +51,7 @@ category: reference
 
 1. 使用 `stop-task` 命令停止当前正在运行的所有同步任务。
 
-2. 使用 Ansible [停止整个 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md#第-10-步-关闭-dm-集群)。
+2. 使用 Ansible [停止整个 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md#第-10-步关闭-dm-集群)。
 
 3. 手动清理掉与 binlog event 被重置的 MySQL master 相对应的 DM-worker 的 relay log 目录。
 
@@ -60,6 +60,6 @@ category: reference
 
 4. 清理掉下游已同步的数据。
 
-5. 使用 Ansible [启动整个 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md#第-9-步-部署-dm-集群)。
+5. 使用 Ansible [启动整个 DM 集群](/dev/how-to/deploy/data-migration-with-ansible.md#第-9-步部署-dm-集群)。
 
 6. 以新的任务名重启数据同步任务，或设置 `remove-meta` 为 `true` 且 `task-mode` 为 `all`。
diff --git a/dev/reference/alert-rules.md b/dev/reference/alert-rules.md
@@ -56,7 +56,7 @@ category: reference
 
 * 处理方法：
 
-    参考 [`TiDB_schema_error`](#tidb-schema-error) 的处理方法。
+    参考 [`TiDB_schema_error`](#tidb_schema_error) 的处理方法。
 
 #### `TiDB_monitor_keep_alive`
 
@@ -459,7 +459,7 @@ category: reference
 
     1. 检查网络是否通畅。
     2. 检查远端 TiKV 是否挂掉。
-    3. 如果远端 TiKV 没有挂掉，检查压力是否太大，参考 [`TiKV_channel_full_total`](#tikv-channel-full-total) 处理方法。
+    3. 如果远端 TiKV 没有挂掉，检查压力是否太大，参考 [`TiKV_channel_full_total`](#tikv_channel_full_total) 处理方法。
 
 #### `TiKV_channel_full_total`
 
@@ -515,7 +515,7 @@ category: reference
 
 * 处理方法：
 
-    参考 [`TiKV_channel_full_total`](#tikv-channel-full-total) 的处理方法。
+    参考 [`TiKV_channel_full_total`](#tikv_channel_full_total) 的处理方法。
 
 #### `TiKV_async_request_write_duration_seconds`
 
@@ -529,7 +529,7 @@ category: reference
 
 * 处理方法：
 
-    1. 检查 Raftstore 上的压力，参考 [`TiKV_channel_full_total`](#tikv-channel-full-total) 的处理方法。
+    1. 检查 Raftstore 上的压力，参考 [`TiKV_channel_full_total`](#tikv_channel_full_total) 的处理方法。
     2. 检查 apply worker 线程的压力。
 
 #### `TiKV_coprocessor_request_wait_seconds`
@@ -560,7 +560,7 @@ category: reference
 
 * 处理方法：
 
-    参考 [`TiKV_channel_full_total`](#tikv-channel-full-total) 的处理方法。
+    参考 [`TiKV_channel_full_total`](#tikv_channel_full_total) 的处理方法。
 
 #### `TiKV_raft_append_log_duration_secs`
 
@@ -639,7 +639,7 @@ category: reference
 
 * 处理方法：
 
-    1. 参考 [`TiKV_channel_full_total`](#tikv-channel-full-total) 的处理方法。
+    1. 参考 [`TiKV_channel_full_total`](#tikv_channel_full_total) 的处理方法。
     2. 如果 TiKV 压力很小，考虑 PD 的调度是否太频繁。可以查看 PD 页面的 Operator Create 面板，排查 PD 产生调度的类型和数量。
 
 #### `TiKV_raft_process_ready_duration_secs`
@@ -679,7 +679,7 @@ category: reference
 
 * 处理方法：
 
-    参考 [`TiKV_scheduler_latch_wait_duration_seconds`](#tikv-scheduler-latch-wait-duration-seconds) 的处理方法。
+    参考 [`TiKV_scheduler_latch_wait_duration_seconds`](#tikv_scheduler_latch_wait_duration_seconds) 的处理方法。
 
 #### `TiKV_scheduler_command_duration_seconds`
 
@@ -693,7 +693,7 @@ category: reference
 
 * 处理方法：
 
-    参考 [`TiKV_scheduler_latch_wait_duration_seconds`](#tikv-scheduler-latch-wait-duration-seconds) 的处理方法。
+    参考 [`TiKV_scheduler_latch_wait_duration_seconds`](#tikv_scheduler_latch_wait_duration_seconds) 的处理方法。
 
 #### `TiKV_coprocessor_outdated_request_wait_seconds`
 
@@ -707,7 +707,7 @@ category: reference
 
 * 处理方法：
 
-    参考 [`TiKV_coprocessor_request_wait_seconds`](#tikv-coprocessor-request-wait-seconds) 的处理方法。
+    参考 [`TiKV_coprocessor_request_wait_seconds`](#tikv_coprocessor_request_wait_seconds) 的处理方法。
 
 #### `TiKV_coprocessor_request_error`
 
@@ -749,7 +749,7 @@ category: reference
 
 * 处理方法：
 
-    参考 [`TiKV_coprocessor_request_wait_seconds`](#tikv-coprocessor-request-wait-seconds) 的处理方法。
+    参考 [`TiKV_coprocessor_request_wait_seconds`](#tikv_coprocessor_request_wait_seconds) 的处理方法。
 
 #### `TiKV_batch_request_snapshot_nums`
 

diff --git a/dev/reference/error-codes.md b/dev/reference/error-codes.md
@@ -16,7 +16,7 @@ TiDB 兼容 MySQL 的错误码，在大多数情况下，返回和 MySQL 一样
 | 8001 | 请求使用的内存超过 TiDB 内存使用的阈值限制 |
 | 8002 | 带有 `SELECT FOR UPDATE` 语句的事务，在遇到写入冲突时，为保证一致性无法进行重试，事务将进行回滚并返回该错误 |
 | 8003 | `ADMIN CHECK TABLE` 命令在遇到行数据跟索引不一致的时候返回该错误 |
-| 8004 | 单个事务过大，原因及解决方法请参考[这里](/dev/faq/tidb.md#出现-transaction-too-large-报错怎么办) |
+| 8004 | 单个事务过大，原因及解决方法请参考[这里](/dev/faq/tidb.md#433-transaction-too-large-是什么原因怎么解决) |
 | 8005 | 事务在 TiDB 中遇到了写入冲突，原因及解决方法请参考[这里](/dev/faq/tidb.md#九故障排除) |
 | 9001 | 请求 PD 超时，请检查 PD Server 状态/监控/日志以及 TiDB Server 与 PD Server 之间的网络 |
 | 9002 | 请求 TiKV 超时，请检查 TiKV Server 状态/监控/日志以及 TiDB Server 与 TiKV Server 之间的网络 |

diff --git a/dev/reference/garbage-collection/configuration.md b/dev/reference/garbage-collection/configuration.md
@@ -81,9 +81,9 @@ update mysql.tidb set VARIABLE_VALUE="24h" where VARIABLE_NAME="tikv_gc_life_tim
 当 `tikv_gc_mode` 设为 `"distributed"`，GC concurrency 将应用于 [Resolve Locks](/dev/reference/garbage-collection/overview.md#resolve-locks) 阶段。当 [`tikv_gc_mode`](#tikv_gc_mode) 设为 `"central"` 时，GC concurrency 将应用于 Resolve Locks 以及 [Do GC](/dev/reference/garbage-collection/overview.md#do-gc) 两个阶段。
 
 - `true`（默认）：自动以 TiKV 节点的个数作为 GC concurrency
-- `false`：使用 [`tikv_gc_concurrency`](#tikv-gc-concurrency) 的值作为 GC 并发数
+- `false`：使用 [`tikv_gc_concurrency`](#tikv_gc_concurrency) 的值作为 GC 并发数
 
 ## `tikv_gc_concurrency`
 
-- 手动设置 GC concurrency。要使用该参数，必须将 [`tikv_gc_auto_concurrency`](#tikv-gc-auto-concurrency) 设为 `false` 。
+- 手动设置 GC concurrency。要使用该参数，必须将 [`tikv_gc_auto_concurrency`](#tikv_gc_auto_concurrency) 设为 `false` 。
 - 默认值：2
diff --git a/dev/reference/mysql-compatibility.md b/dev/reference/mysql-compatibility.md
@@ -73,7 +73,7 @@ TiDB 的查询计划（`EXPLAIN`/`EXPLAIN FOR`）输出格式与 MySQL 差别较
 
 ### 内建函数
 
-TiDB 支持常用的 MySQL 内建函数，但是不是所有的函数都已经支持，具体请参考[语法文档](https://pingcap.github.io/sqlgram/#FunctionCallKeyword)。
+TiDB 支持常用的 MySQL 内建函数，但是不是所有的函数都已经支持，具体请参考[语法文档](https://pingcap.github.io/sqlgram/#functioncallkeyword)。
 
 ### DDL
 

diff --git a/dev/reference/performance/check-cluster-status-using-sql-statements.md b/dev/reference/performance/check-cluster-status-using-sql-statements.md
@@ -10,17 +10,17 @@ category: reference
 `INFORMATION_SCHEMA` 中提供了如下几个系统表，用于查询集群状态，诊断常见的集群问题。
 
 - [`TABLES`](/dev/reference/system-databases/information-schema.md#tables-表)
-- [`TIDB_INDEXES`](/dev/reference/system-databases/information-schema.md#tidb-indexes-表)
-- [`ANALYZE_STATUS`](/dev/reference/system-databases/information-schema.md#analyze-status-表)
-- [`TIDB_HOT_REGIONS`](/dev/reference/system-databases/information-schema.md#tidb-hot-regions-表)
-- [`TIKV_STORE_STATUS`](/dev/reference/system-databases/information-schema.md#tikv-store-status-表)
-- [`TIKV_REGION_STATUS`](/dev/reference/system-databases/information-schema.md#tikv-region-status-表)
-- [`TIKV_REGION_PEERS`](/dev/reference/system-databases/information-schema.md#tikv-region-peers-表)
+- [`TIDB_INDEXES`](/dev/reference/system-databases/information-schema.md#tidb_indexes-表)
+- [`ANALYZE_STATUS`](/dev/reference/system-databases/information-schema.md#analyze_status-表)
+- [`TIDB_HOT_REGIONS`](/dev/reference/system-databases/information-schema.md#tidb_hot_regions-表)
+- [`TIKV_STORE_STATUS`](/dev/reference/system-databases/information-schema.md#tikv_store_status-表)
+- [`TIKV_REGION_STATUS`](/dev/reference/system-databases/information-schema.md#tikv_region_status-表)
+- [`TIKV_REGION_PEERS`](/dev/reference/system-databases/information-schema.md#tikv_region_peers-表)
 
 除此之外，执行下列语句也可获得对排查问题或查询集群状态有用的信息：
 
 - `ADMIN SHOW DDL` 可以获得是 `DDL owner` 角色的 TiDB 的 ID 及 `IP:PORT` 等具体信息。
-- `SHOW ANALYZE STATUS` 和 [`ANALYZE_STATUS`](/dev/reference/system-databases/information-schema.md#analyze-status-表) 表的功能相同。
+- `SHOW ANALYZE STATUS` 和 [`ANALYZE_STATUS`](/dev/reference/system-databases/information-schema.md#analyze_status-表) 表的功能相同。
 - 特殊的 `EXPLAIN` 语句：
     - `EXPLAIN ANALYZE` 语句可以获得一个 SQL 语句执行中的一些具体信息。
     - `EXPLAIN FOR CONNECTION` 可以获得一个连接中最后执行的查询的执行计划。可以配合 `SHOW PROCESSLIST` 使用。

diff --git a/dev/reference/performance/understanding-the-query-execution-plan.md b/dev/reference/performance/understanding-the-query-execution-plan.md
@@ -12,12 +12,12 @@ TiDB 优化器会根据当前数据表的实际情况来选择最优的执行计
 `EXPLAIN` 语句的返回结果提供了 TiDB 执行 SQL 查询的详细信息：
 
 - `EXPLAIN` 可以和 `SELECT`，`DELETE` 语句一起使用；
-- 执行 `EXPLAIN`，TiDB 会返回被 `EXPLAIN` 的 SQL 语句经过优化器后的最终物理执行计划。也就是说，`EXPLAIN` 展示了 TiDB 执行该 SQL 语句的完整信息，比如以什么样的顺序，什么方式 JOIN 两个表，表达式树长什么样等等。详见 [`EXPLAIN` 输出格式](#explain-output-format)；
+- 执行 `EXPLAIN`，TiDB 会返回被 `EXPLAIN` 的 SQL 语句经过优化器后的最终物理执行计划。也就是说，`EXPLAIN` 展示了 TiDB 执行该 SQL 语句的完整信息，比如以什么样的顺序，什么方式 JOIN 两个表，表达式树长什么样等等。详见 [`EXPLAIN` 输出格式](#explain-输出格式)；
 - TiDB 支持 `EXPLAIN [options] FOR CONNECTION connection_id`，但与 MySQL 的 `EXPLAIN FOR` 有一些区别，请参见 [`EXPLAIN FOR CONNECTION`](#explain-for-connection)。
 
 通过观察 `EXPLAIN` 的结果，你可以知道如何给数据表添加索引使得执行计划使用索引从而加速 SQL 语句的执行速度；你也可以使用 `EXPLAIN` 来检查优化器是否选择了最优的顺序来 JOIN 数据表。
 
-## <span id="explain-output-format">`EXPLAIN` 输出格式</span>
+## `EXPLAIN` 输出格式
 
 目前 TiDB 的 `EXPLAIN` 会输出 4 列，分别是：id，count，task，operator info。执行计划中每个算子都由这 4 列属性来描述，`EXPLAIN` 结果中每一行描述一个算子。每个属性的具体含义如下：
 
@@ -28,7 +28,7 @@ TiDB 优化器会根据当前数据表的实际情况来选择最优的执行计
 | task          | 当前这个算子属于什么 task。目前的执行计划分成为两种 task，一种叫 **root** task，在 tidb-server 上执行，一种叫 **cop** task，并行的在 TiKV 上执行。当前的执行计划在 task 级别的拓扑关系是一个 root task 后面可以跟许多 cop task，root task 使用 cop task 的输出结果作为输入。cop task 中执行的也即是 TiDB 下推到 TiKV 上的任务，每个 cop task 分散在 TiKV 集群中，由多个进程共同执行。 |
 | operator info | 每个算子的详细信息。各个算子的 operator info 各有不同，详见 [Operator Info](#operator-info)。                   |
 
-## <span id="explain-analyze-output-format">`EXPLAIN ANALYZE` 输出格式</span>
+## `EXPLAIN ANALYZE` 输出格式
 
 作为 `EXPLAIN` 语句的扩展，`EXPLAIN ANALYZE` 语句执行查询并在 `execution info` 列中提供额外的执行统计信息。具体如下：
 

diff --git a/dev/reference/sql/functions-and-operators/json-functions.md b/dev/reference/sql/functions-and-operators/json-functions.md
@@ -5,7 +5,7 @@ category: reference
 
 # JSON 函数及语法糖
 
-TiDB 支持 MySQL 5.7 GA 版本发布的大多数 JSON 函数。MySQL 5.7 发布后，又增加了更多 JSON 函数，TiDB 并未支持所有这些函数（参见[未支持的函数](#unsupported-functions)）。
+TiDB 支持 MySQL 5.7 GA 版本发布的大多数 JSON 函数。MySQL 5.7 发布后，又增加了更多 JSON 函数，TiDB 并未支持所有这些函数（参见[未支持的函数](#未支持的函数)）。
 
 ## 创建 JSON 值的函数
 

diff --git a/dev/reference/sql/language-structure/comment-syntax.md b/dev/reference/sql/language-structure/comment-syntax.md
@@ -84,6 +84,6 @@ SELECT /*+ hint */ FROM ...;
 
 由于 hint 包含在类似 /*+ xxx */ 的 comment 里，MySQL 客户端在 5.7.7 之前，会默认把 comment 清除掉，如果需要在旧的客户端使用 hint，需要在启动客户端时加上 --comments 选项，例如 mysql -h 127.0.0.1 -P 4000 -uroot --comments
 
-TiDB 支持的相关优化器 hint 详见[这里](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#optimizer-hint)
+TiDB 支持的相关优化器 hint 详见[这里](/dev/reference/performance/optimizer-hints.md)
 
 更多[细节](https://dev.mysql.com/doc/refman/5.7/en/comments.html)。
diff --git a/dev/reference/sql/statements/create-index.md b/dev/reference/sql/statements/create-index.md
@@ -83,7 +83,7 @@ Query OK, 0 rows affected (0.31 sec)
 
 ## 相关 session 变量
 
-和 `CREATE INDEX` 语句相关的全局变量有 `tidb_ddl_reorg_worker_cnt`，`tidb_ddl_reorg_batch_size` 和 `tidb_ddl_reorg_priority`，具体可以参考 [TiDB 特定系统变量](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#tidb-ddl-reorg-worker-cnt)。
+和 `CREATE INDEX` 语句相关的全局变量有 `tidb_ddl_reorg_worker_cnt`，`tidb_ddl_reorg_batch_size` 和 `tidb_ddl_reorg_priority`，具体可以参考 [TiDB 特定系统变量](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#tidb_ddl_reorg_worker_cnt)。
 
 ## MySQL 兼容性
 

diff --git a/dev/reference/sql/statements/create-table.md b/dev/reference/sql/statements/create-table.md
@@ -206,7 +206,7 @@ table_option:
   | STATS_PERSISTENT [=] {DEFAULT|0|1}
 ```
 
-`table_option` 目前支持的只有 `AUTO_INCREMENT`、`SHARD_ROW_ID_BITS`（详情介绍请参考 [TiDB 专用系统变量和语法](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#shard-row-id-bits)）、`PRE_SPLIT_REGIONS`、`CHARACTER SET`、`COLLATE` 和 `COMMENT`，其它只是语法上支持。具体内容参考下表，各个子句之间用逗号隔开。
+`table_option` 目前支持的只有 `AUTO_INCREMENT`、`SHARD_ROW_ID_BITS`（详情介绍请参考 [TiDB 专用系统变量和语法](/dev/reference/configuration/tidb-server/tidb-specific-variables.md#shard_row_id_bits)）、`PRE_SPLIT_REGIONS`、`CHARACTER SET`、`COLLATE` 和 `COMMENT`，其它只是语法上支持。具体内容参考下表，各个子句之间用逗号隔开。
 
 | 参数           |含义                                  |举例                      |
 |----------------|--------------------------------------|----------------------------|