From b9bb251653504e94db305e5efe5944399b11dfb8 Mon Sep 17 00:00:00 2001 From: lhyPingcap <34829765+lhyPingcap@users.noreply.github.com> Date: Tue, 7 Aug 2018 19:40:51 +0800 Subject: [PATCH 1/5] Update FAQ.md --- FAQ.md | 44 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 42 insertions(+), 2 deletions(-) diff --git a/FAQ.md b/FAQ.md index 9cebc8644e27..4e69330b1785 100755 --- a/FAQ.md +++ b/FAQ.md @@ -104,7 +104,7 @@ TiDB 的 `show processlist` 与 MySQL 的 `show processlist` 显示内容基本 TiDB 作为分布式数据库，在 TiDB 中修改用户密码建议使用 `set password for 'root'@'%' = '0101001';` 或 `alter` 方法，不推荐使用 `update mysql.user` 的方法进行，这种方法可能会造成其它节点刷新不及时的情况。修改权限也一样，都建议采用官方的标准语法。详情可参考 [TiDB 用户账户管理](sql/user-account-management.md)。 -#### 1.1.22 TiDB中，为什么出现后插入数据的自增 ID 反而小？ +#### 1.1.22 TiDB 中，为什么出现后插入数据的自增 ID 反而小？ TiDB 的自增 ID (`AUTO_INCREMENT`) 只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配的方式，所以如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。当多个线程并发往不同的 tidb-server 插入数据的时候，有可能会出现后插入的数据自增 ID 小的情况。此外，TiDB允许给整型类型的字段指定 AUTO_INCREMENT，且一个表只允许一个属性为 `AUTO_INCREMENT` 的字段。详情可参考[数据定义语句](sql/ddl.md)。 @@ -508,6 +508,46 @@ information_schema 库中的 tables 表里的 create_time 即为表的真实创 TiDB 在执行 SQL 时，预估出来每个 operator 处理了超过 10000 条数据就认为这条 query 是 expensive query。可以通过修改 tidb-server 配置参数来对这个门限值进行调整，调整后需要重新启动 tidb-server。 +#### 3.3.10 在 TiDB 中如何控制或改变 SQL 提交的执行优先级？ + +首先需要了解高优先级和低优先级的语法元素 + +- HIGH_PRIORITY：该语句为高优先级语句，TiDB 在执行阶段会优先处理这条语句 +- LOW_PRIORITY：该语句为低优先级语句，TiDB 在执行阶段会降低这条语句的优先级 + +以上两种参数可以结合 TiDB 的 DML 语言进行使用，具体使用方式可以参考[官方文档](https://pingcap.com/docs-cn/sql/dml/)，使用方法举例如下： + +1）通过在数据库中写 SQL 的方式来调整优先级： + +``` +select HIGH_PRIORITY | LOW_PRIORITY count(*) from table_name; +insert HIGH_PRIORITY | LOW_PRIORITY into table_name insert_values; +delete HIGH_PRIORITY | LOW_PRIORITY from table_name; +update HIGH_PRIORITY | LOW_PRIORITY table_reference set assignment_list where where_condition; +replace HIGH_PRIORITY | LOW_PRIORITY into table_name; +``` +2）全表扫会自动调整为低优先级，analyze 也是默认低优先级。 + +#### 3.3.11 在 TiDB 中 auto analyze 的触发策略是怎样的？ + +触发策略：新表达到 1000 条，会自动触发。 + +当表的 (修改数/当前总行数) 大于 `tidb_auto_analyze_ratio` 的时候，会自动触发 analyze 语句。`tidb_auto_analyze_ratio` 的默认值为 0，即关闭此功能。为了保险起见，在开启此功能的时候，保证了其最小值为 0.3。但是不能大于等于 `pseudo-estimate-ratio` (默认值为 0.7），否则会有一段时间使用 pseudo 统计信息，建议设置值为 0.5。 + +#### 3.3.12 Select 语句在 TiDB 的 RC 与 RR 隔离级别下的实现过程，以及对应用的影响。 + +TiDB 实现了两种隔离级别：读已提交和可重复读。 + +Select 在不同的隔离级别上，会有不同的执行逻辑和表现形式： + +- 首先，select 在 RC 隔离级别下，不会到 PD 拿时间戳，直接用最大的 timestamp 去读数据，读取到当前最新的已经提交成功的数据。但在 RC 模式下，也会出现 RC 事务隔离级别本身的问题，即会出现幻读和不可重复读的情况。 +- RR 隔离级别还是要到 PD 去拿 timestamp ，通过 timestamp 以及 precolator 算法来读取多版本数据，防止读到被其他事务/会话修改过的数据，从而避免了幻读和不可重复读的问题。 + +#### 3.3.13 SQL 中如何通过 hint 使用一个具体的 index？ + +同 MySQL 的 用法一致，例如： +`select column_name from table_name use index（index_name）where where_condition;` + ### 3.4 TiKV 管理 #### 3.4.1 TiKV 集群副本建议配置数量是多少，是不是最小高可用配置（3个）最好？ @@ -542,7 +582,7 @@ TiKV 使用了 RocksDB 的 Column Family (CF) 特性，KV 数据最终存储在 - Raftstore 线程卡了，可以看一下 Raftstore 的 CPU 使用情况。 - TiKV 太忙了（读取、写入、磁盘 I/O 等），请求处理不过来。 -#### 3.4.7 TiKV 频繁切换 Region leader 切换是啥原因？ +#### 3.4.7 TiKV 频繁切换 Region leader 是什么原因？ - 网络问题导致节点间通信卡了，查看 Report failures 监控。 - 原主 Leader 的节点卡了，导致没有及时给 Follower 发送消息。 From a4b013f036d9fda0c81011b47f2dab3ca717ca69 Mon Sep 17 00:00:00 2001 From: lhyPingcap <34829765+lhyPingcap@users.noreply.github.com> Date: Wed, 8 Aug 2018 11:12:16 +0800 Subject: [PATCH 2/5] Update FAQ.md --- FAQ.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/FAQ.md b/FAQ.md index 4e69330b1785..6bac83d965fd 100755 --- a/FAQ.md +++ b/FAQ.md @@ -515,7 +515,7 @@ TiDB 在执行 SQL 时，预估出来每个 operator 处理了超过 10000 条 - HIGH_PRIORITY：该语句为高优先级语句，TiDB 在执行阶段会优先处理这条语句 - LOW_PRIORITY：该语句为低优先级语句，TiDB 在执行阶段会降低这条语句的优先级 -以上两种参数可以结合 TiDB 的 DML 语言进行使用，具体使用方式可以参考[官方文档](https://pingcap.com/docs-cn/sql/dml/)，使用方法举例如下： +以上两种参数可以结合 TiDB 的 DML 语言进行使用，具体使用方式可以参考[官方文档](sql/dml.md)，使用方法举例如下： 1）通过在数据库中写 SQL 的方式来调整优先级： @@ -526,22 +526,23 @@ delete HIGH_PRIORITY | LOW_PRIORITY from table_name; update HIGH_PRIORITY | LOW_PRIORITY table_reference set assignment_list where where_condition; replace HIGH_PRIORITY | LOW_PRIORITY into table_name; ``` + 2）全表扫会自动调整为低优先级，analyze 也是默认低优先级。 #### 3.3.11 在 TiDB 中 auto analyze 的触发策略是怎样的？ 触发策略：新表达到 1000 条，会自动触发。 -当表的 (修改数/当前总行数) 大于 `tidb_auto_analyze_ratio` 的时候，会自动触发 analyze 语句。`tidb_auto_analyze_ratio` 的默认值为 0，即关闭此功能。为了保险起见，在开启此功能的时候，保证了其最小值为 0.3。但是不能大于等于 `pseudo-estimate-ratio` (默认值为 0.7），否则会有一段时间使用 pseudo 统计信息，建议设置值为 0.5。 +当表的（修改数/当前总行数）大于 `tidb_auto_analyze_ratio` 的时候，会自动触发 analyze 语句。`tidb_auto_analyze_ratio` 的默认值为 0，即关闭此功能。为了保险起见，在开启此功能的时候，保证了其最小值为 0.3。但是不能大于等于 `pseudo-estimate-ratio`（默认值为 0.7），否则会有一段时间使用 pseudo 统计信息，建议设置值为 0.5。 -#### 3.3.12 Select 语句在 TiDB 的 RC 与 RR 隔离级别下的实现过程，以及对应用的影响。 +#### 3.3.12 Select 语句在 TiDB 的 RC 与 RR 隔离级别下的实现过程，以及对应用的影响是怎样的？ -TiDB 实现了两种隔离级别：读已提交和可重复读。 +TiDB 实现了两种隔离级别：读已提交（Read Committed, RC）和可重复读（Repeatable Read, RR）。 Select 在不同的隔离级别上，会有不同的执行逻辑和表现形式： -- 首先，select 在 RC 隔离级别下，不会到 PD 拿时间戳，直接用最大的 timestamp 去读数据，读取到当前最新的已经提交成功的数据。但在 RC 模式下，也会出现 RC 事务隔离级别本身的问题，即会出现幻读和不可重复读的情况。 -- RR 隔离级别还是要到 PD 去拿 timestamp ，通过 timestamp 以及 precolator 算法来读取多版本数据，防止读到被其他事务/会话修改过的数据，从而避免了幻读和不可重复读的问题。 +- 首先，select 在 RC 隔离级别下，不会到 PD 拿时间戳，而是直接用最大的 timestamp 去读数据，读取到当前最新的已经提交成功的数据。但在 RC 模式下，也会出现 RC 事务隔离级别本身的问题，即会出现幻读和不可重复读的情况。 +- RR 隔离级别还是要到 PD 去拿 timestamp，通过 timestamp 以及 Precolator 算法来读取多版本数据，防止读到被其他事务/会话修改过的数据，从而避免了幻读和不可重复读的问题。 #### 3.3.13 SQL 中如何通过 hint 使用一个具体的 index？ From c6c8b270687fb7645dd2cbbe15c1f5b65e03934f Mon Sep 17 00:00:00 2001 From: lhyPingcap <34829765+lhyPingcap@users.noreply.github.com> Date: Wed, 8 Aug 2018 13:42:37 +0800 Subject: [PATCH 3/5] Update FAQ.md --- FAQ.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/FAQ.md b/FAQ.md index 6bac83d965fd..80fb81ee180a 100755 --- a/FAQ.md +++ b/FAQ.md @@ -510,7 +510,7 @@ TiDB 在执行 SQL 时，预估出来每个 operator 处理了超过 10000 条 #### 3.3.10 在 TiDB 中如何控制或改变 SQL 提交的执行优先级？ -首先需要了解高优先级和低优先级的语法元素 +首先需要了解高优先级和低优先级的语法元素： - HIGH_PRIORITY：该语句为高优先级语句，TiDB 在执行阶段会优先处理这条语句 - LOW_PRIORITY：该语句为低优先级语句，TiDB 在执行阶段会降低这条语句的优先级 @@ -537,7 +537,7 @@ replace HIGH_PRIORITY | LOW_PRIORITY into table_name; #### 3.3.12 Select 语句在 TiDB 的 RC 与 RR 隔离级别下的实现过程，以及对应用的影响是怎样的？ -TiDB 实现了两种隔离级别：读已提交（Read Committed, RC）和可重复读（Repeatable Read, RR）。 +TiDB 实现了两种隔离级别：读已提交 (Read Committed, RC) 和可重复读 (Repeatable Read, RR)。 Select 在不同的隔离级别上，会有不同的执行逻辑和表现形式： From 01a034270978630f3625df71b98d600088ad1a87 Mon Sep 17 00:00:00 2001 From: Lilian Lee Date: Mon, 13 Aug 2018 11:00:15 +0800 Subject: [PATCH 4/5] FAQ: update wording --- FAQ.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/FAQ.md b/FAQ.md index 80fb81ee180a..7b70d2cb8f63 100755 --- a/FAQ.md +++ b/FAQ.md @@ -510,7 +510,7 @@ TiDB 在执行 SQL 时，预估出来每个 operator 处理了超过 10000 条 #### 3.3.10 在 TiDB 中如何控制或改变 SQL 提交的执行优先级？ -首先需要了解高优先级和低优先级的语法元素： +TiDB 中高优先级和低优先级的语法元素如下： - HIGH_PRIORITY：该语句为高优先级语句，TiDB 在执行阶段会优先处理这条语句 - LOW_PRIORITY：该语句为低优先级语句，TiDB 在执行阶段会降低这条语句的优先级 @@ -535,14 +535,14 @@ replace HIGH_PRIORITY | LOW_PRIORITY into table_name; 当表的（修改数/当前总行数）大于 `tidb_auto_analyze_ratio` 的时候，会自动触发 analyze 语句。`tidb_auto_analyze_ratio` 的默认值为 0，即关闭此功能。为了保险起见，在开启此功能的时候，保证了其最小值为 0.3。但是不能大于等于 `pseudo-estimate-ratio`（默认值为 0.7），否则会有一段时间使用 pseudo 统计信息，建议设置值为 0.5。 -#### 3.3.12 Select 语句在 TiDB 的 RC 与 RR 隔离级别下的实现过程，以及对应用的影响是怎样的？ +#### 3.3.12 `SELECT` 语句在 TiDB 的 RC 与 RR 隔离级别下的实现过程，以及对应用的影响是怎样的？ TiDB 实现了两种隔离级别：读已提交 (Read Committed, RC) 和可重复读 (Repeatable Read, RR)。 -Select 在不同的隔离级别上，会有不同的执行逻辑和表现形式： +在不同的隔离级别上，`SELECT` 语句有不同的执行逻辑和表现形式，具体如下： -- 首先，select 在 RC 隔离级别下，不会到 PD 拿时间戳，而是直接用最大的 timestamp 去读数据，读取到当前最新的已经提交成功的数据。但在 RC 模式下，也会出现 RC 事务隔离级别本身的问题，即会出现幻读和不可重复读的情况。 -- RR 隔离级别还是要到 PD 去拿 timestamp，通过 timestamp 以及 Precolator 算法来读取多版本数据，防止读到被其他事务/会话修改过的数据，从而避免了幻读和不可重复读的问题。 +- 在 RC 隔离级别下，`SELECT` 不会到 PD 拿时间戳，而是直接用最大的 timestamp 去读数据，读取到当前最新的已经提交成功的数据。但在 RC 模式下，也会出现 RC 事务隔离级别本身的问题，即会出现幻读和不可重复读的情况。 +- 在 RR 隔离级别下，`SELECT` 还是要到 PD 去拿 timestamp，通过 timestamp 以及 Precolator 算法来读取多版本数据，防止读到被其他事务/会话修改过的数据，从而避免了幻读和不可重复读的问题。 #### 3.3.13 SQL 中如何通过 hint 使用一个具体的 index？ From b925a593e531f078deed1e1e6aeed8edda07b4e4 Mon Sep 17 00:00:00 2001 From: lhyPingcap <34829765+lhyPingcap@users.noreply.github.com> Date: Mon, 13 Aug 2018 19:36:07 +0800 Subject: [PATCH 5/5] Update FAQ.md --- FAQ.md | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/FAQ.md b/FAQ.md index 7b70d2cb8f63..2be8bd637ae6 100755 --- a/FAQ.md +++ b/FAQ.md @@ -531,20 +531,11 @@ replace HIGH_PRIORITY | LOW_PRIORITY into table_name; #### 3.3.11 在 TiDB 中 auto analyze 的触发策略是怎样的？ -触发策略：新表达到 1000 条，会自动触发。 +触发策略：新表达到 1000 条，并且在 1 分钟内没有写入，会自动触发。 当表的（修改数/当前总行数）大于 `tidb_auto_analyze_ratio` 的时候，会自动触发 analyze 语句。`tidb_auto_analyze_ratio` 的默认值为 0，即关闭此功能。为了保险起见，在开启此功能的时候，保证了其最小值为 0.3。但是不能大于等于 `pseudo-estimate-ratio`（默认值为 0.7），否则会有一段时间使用 pseudo 统计信息，建议设置值为 0.5。 -#### 3.3.12 `SELECT` 语句在 TiDB 的 RC 与 RR 隔离级别下的实现过程，以及对应用的影响是怎样的？ - -TiDB 实现了两种隔离级别：读已提交 (Read Committed, RC) 和可重复读 (Repeatable Read, RR)。 - -在不同的隔离级别上，`SELECT` 语句有不同的执行逻辑和表现形式，具体如下： - -- 在 RC 隔离级别下，`SELECT` 不会到 PD 拿时间戳，而是直接用最大的 timestamp 去读数据，读取到当前最新的已经提交成功的数据。但在 RC 模式下，也会出现 RC 事务隔离级别本身的问题，即会出现幻读和不可重复读的情况。 -- 在 RR 隔离级别下，`SELECT` 还是要到 PD 去拿 timestamp，通过 timestamp 以及 Precolator 算法来读取多版本数据，防止读到被其他事务/会话修改过的数据，从而避免了幻读和不可重复读的问题。 - -#### 3.3.13 SQL 中如何通过 hint 使用一个具体的 index？ +#### 3.3.12 SQL 中如何通过 hint 使用一个具体的 index？ 同 MySQL 的 用法一致，例如： `select column_name from table_name use index（index_name）where where_condition;`