Merge remote-tracking branch 'upstream/master'

basic-features.md

@@ -174,7 +174,6 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0
 | [扩展统计信息](/extended-statistics.md) |  E  |  E   | E | E | E | E | E | E | E |
 | 统计反馈 |  N  |  N   | N | N | 已废弃 | 已废弃 | E | E | E |
 | [统计信息自动更新](/statistics.md#自动更新) |  Y  | Y | Y | Y | Y | Y | Y | Y | Y |
-| [快速分析](/system-variables.md#tidb_enable_fast_analyze) | 已废弃 | 已废弃  | E | E | E | E | E | E | E |
 | [动态裁剪](/partitioned-table.md#动态裁剪模式) |  Y   |  Y   | Y | Y | Y | E | E | E | E |
 | [收集部分列的统计信息](/statistics.md#收集部分列的统计信息) |  E   |  E   | E | E | E | E | N | N | N |
 | [限制统计信息的内存使用量](/statistics.md#统计信息收集的内存限制) |  E  |  E   | E | E | E | N | N | N | N |

best-practices/uuid.md

@@ -7,17 +7,17 @@ summary: 了解在 TiDB 中使用 UUID 的最佳实践和策略。
 
 ## UUID 概述
 
-通用唯一标识符（UUID）用作主键而不是 `AUTO_INCREMENT` 整数值时，可以提供以下好处：
+通用唯一标识符 (UUID) 用作主键而不是 [`AUTO_INCREMENT`](/auto-increment.md) 整数值时，可以提供以下好处：
 
 - UUID 可以在多个系统生成，而不会产生冲突。某些情况下可以减少到 TiDB 的网络往返次数，从而提高性能。
 - 绝大多数编程语言和数据库系统都支持 UUID。
-- 用在 URL 中时，UUID 不容易被枚举攻击。相比之下，使用 `auto_increment` 数字，则很容易让发票 ID 或用户 ID 被猜出。
+- 用在 URL 中时，UUID 不容易被枚举攻击。相比之下，使用 `AUTO_INCREMENT` 数字，则很容易让发票 ID 或用户 ID 被猜出。
 
 ## 最佳实践
 
 ### 二进制存储
 
-UUID 文本是一个包含 36 字符的字符串，如 `ab06f63e-8fe7-11ec-a514-5405db7aad56`。使用 `UUID_TO_BIN()` 可将 UUID 文本格式转换为 16 字节的二进制格式。这样，你可以将文本存储在 `BINARY(16)` 列中。检索 UUID 时，可以使用 `BIN_TO_UUID()` 函数再将其转换回文本格式。
+UUID 文本是一个包含 36 字符的字符串，如 `ab06f63e-8fe7-11ec-a514-5405db7aad56`。使用 [`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin) 可将 UUID 文本格式转换为 16 字节的二进制格式。这样，你可以将文本存储在 [`BINARY(16)`](/data-type-string.md#binary-类型) 列中。检索 UUID 时，可以使用 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid) 函数再将其转换回文本格式。
 
 ### UUID 格式二进制顺序和聚簇主键
 

br/br-incremental-guide.md

@@ -11,6 +11,12 @@ TiDB 集群增量数据包含在某个时间段的起始和结束两个快照的
 >
 > 当前该功能已经停止开发迭代，推荐你选择[日志备份与恢复功能](/br/br-pitr-guide.md)代替。
 
+## 使用限制
+
+由于增量备份的恢复依赖于备份时间点的库表快照来过滤增量 DDL，因此对于增量备份过程中删除的表，在恢复后可能仍然存在，需要手动删除。
+
+增量备份尚不支持批量重命名表的操作。如果在增量备份过程中发生了批量重命名表的操作，则有可能造成恢复失败。建议在批量重命名表后进行一次全量备份，并在恢复时使用最新的全量备份替代增量数据。
+
 ## 对集群进行增量备份
 
 使用 `tiup br backup` 进行增量备份只需要指定**上一次的备份时间戳** `--lastbackupts`，br 命令行工具会判定需要备份 `lastbackupts` 和当前时间之间增量数据。使用 `validate` 指令获取上一次备份的时间戳，示例如下：

br/br-snapshot-guide.md

@@ -175,13 +175,11 @@ tiup br restore full \
 +-----------------------------------------------------+
 ```
 
-当恢复系统权限相关数据的时候，请注意：
+当恢复系统权限相关数据的时候，请注意：在恢复数据前 BR 会检查目标集群的系统表是否跟备份数据中的系统表兼容。这里的兼容是指满足以下所有条件：
 
-- 在 v7.6.0 之前版本中，BR 无法恢复 `user` 为 `cloud_admin` 并且 `host` 为 `'%'` 的用户数据，该用户是 TiDB Cloud 预留用户。从 v7.6.0 开始，BR 默认支持恢复包括 `cloud_admin` 在内的所有用户数据。
-- 在恢复数据前 BR 会检查目标集群的系统表是否跟备份数据中的系统表兼容。这里的兼容是指满足以下所有条件：
-    - 目标集群需要存在备份中的系统权限表。
-    - 目标集群系统权限表**列数**需要与备份数据中一致，列的顺序可以有差异。
-    - 目标集群系统权限表的列需要与备份数据兼容。如果为带长度类型（包括整型、字符串等类型），前者长度需大于或等于后者，如果为 `ENUM` 类型，则应该为后者超集。
+- 目标集群需要存在备份中的系统权限表。
+- 目标集群系统权限表**列数**需要与备份数据中一致，列的顺序可以有差异。
+- 目标集群系统权限表的列需要与备份数据兼容。如果为带长度类型（包括整型、字符串等类型），前者长度需大于或等于后者，如果为 `ENUM` 类型，则应该为后者超集。
 
 ## 性能与影响
 

functions-and-operators/tidb-functions.md

@@ -312,12 +312,14 @@ select tidb_decode_sql_digests(@digests, 10);
 SET GLOBAL tidb_enable_row_level_checksum = ON;
 ```
 
+上述配置仅对新创建的会话生效，因此需要重新连接 TiDB。
+
 创建表 `t` 并插入数据：
 
 ```sql
 USE test;
-CREATE TABLE t (id INT PRIMARY KEY, k INT, c int);
-INSERT INTO TABLE t values (1, 10, a);
+CREATE TABLE t (id INT PRIMARY KEY, k INT, c CHAR(1));
+INSERT INTO t values (1, 10, 'a');
 ```
 
 查询表 `t` 中 `id = 1` 的行数据的 Checksum 值：

hardware-and-software-requirements.md

@@ -23,6 +23,7 @@ TiDB 作为一款开源一栈式实时 HTAP 数据库，可以很好地部署和
 | Red Hat Enterprise Linux 8.4 及以上的 8.x 版本  |  <ul><li>x86_64</li><li>ARM 64</li></ul>  |
 | <ul><li>Red Hat Enterprise Linux 7.3 及以上的 7.x 版本</li><li>CentOS 7.3 及以上的 7.x 版本</li></ul>  |  <ul><li>x86_64</li><li>ARM 64</li></ul>   |
 |  Amazon Linux 2         |  <ul><li>x86_64</li><li>ARM 64</li></ul>   |
+|  Amazon Linux 2023      |  <ul><li>x86_64</li><li>ARM 64</li></ul>   |
 |  Rocky Linux 9.1 及以上的版本 |  <ul><li>x86_64</li><li>ARM 64</li></ul> |
 | 麒麟欧拉版 V10 SP1/SP2   |   <ul><li>x86_64</li><li>ARM 64</li></ul>   |
 | 统信操作系统 (UOS) V20                 |   <ul><li>x86_64</li><li>ARM 64</li></ul>   |

information-schema/information-schema-tikv-region-status.md

@@ -8,13 +8,13 @@ aliases: ['/docs-cn/dev/information-schema/information-schema-tikv-region-status
 
 `TIKV_REGION_STATUS` 表通过 PD 的 API 展示 TiKV Region 的基本信息，比如 Region ID、开始和结束键值以及读写流量。
 
-{{< copyable "sql" >}}
-
 ```sql
-USE information_schema;
-DESC tikv_region_status;
+USE INFORMATION_SCHEMA;
+DESC TIKV_REGION_STATUS;
 ```
 
+输出结果如下：
+
 ```sql
 +---------------------------+-------------+------+------+---------+-------+
 | Field                     | Type        | Null | Key  | Default | Extra |
@@ -28,6 +28,9 @@ DESC tikv_region_status;
 | IS_INDEX                  | tinyint(1)  | NO   |      | 0       |       |
 | INDEX_ID                  | bigint(21)  | YES  |      | NULL    |       |
 | INDEX_NAME                | varchar(64) | YES  |      | NULL    |       |
+| IS_PARTITION              | tinyint(1)  | NO   |      | 0       |       |
+| PARTITION_ID              | bigint(21)  | YES  |      | NULL    |       |
+| PARTITION_NAME            | varchar(64) | YES  |      | NULL    |       |
 | EPOCH_CONF_VER            | bigint(21)  | YES  |      | NULL    |       |
 | EPOCH_VERSION             | bigint(21)  | YES  |      | NULL    |       |
 | WRITTEN_BYTES             | bigint(21)  | YES  |      | NULL    |       |
@@ -37,7 +40,7 @@ DESC tikv_region_status;
 | REPLICATIONSTATUS_STATE   | varchar(64) | YES  |      | NULL    |       |
 | REPLICATIONSTATUS_STATEID | bigint(21)  | YES  |      | NULL    |       |
 +---------------------------+-------------+------+------+---------+-------+
-17 rows in set (0.00 sec)
+20 rows in set (0.00 sec)
 ```
 
 `TIKV_REGION_STATUS` 表中列的含义如下：
@@ -51,6 +54,9 @@ DESC tikv_region_status;
 * `IS_INDEX`：Region 数据是否是索引，0 代表不是索引，1 代表是索引。如果当前 Region 同时包含表数据和索引数据，会有多行记录，`IS_INDEX` 分别是 0 和 1。
 * `INDEX_ID`：Region 所属的索引的 ID。如果 `IS_INDEX` 为 0，这一列的值就为 NULL。
 * `INDEX_NAME`：Region 所属的索引的名称。如果 `IS_INDEX` 为 0，这一列的值就为 NULL。
+* `IS_PARTITION`：Region 所属的表是否为分区表。
+* `PARTITION_ID`：如果 Region 所属的表为分区表，显示 Region 所属的分区的 ID。
+* `PARTITION_NAME`：如果 Region 所属的表为分区表，显示 Region 所属的分区的名字。
 * `EPOCH_CONF_VER`：Region 的配置的版本号，在增加或减少 peer 时版本号会递增。
 * `EPOCH_VERSION`：Region 的当前版本号，在分裂或合并时版本号会递增。
 * `WRITTEN_BYTES`：已经往 Region 写入的数据量 (bytes)。

migrate-from-csv-files-to-tidb.md

@@ -61,6 +61,8 @@ data-source-dir = "${data-path}" # 本地或 S3 路径，例如：'s3://my-bucke
 separator = ','
 # 引用定界符，可以为零或多个字符。
 delimiter = '"'
+# 行结束符。默认将 \r、\n、\r\n 都作为行结束符处理。
+# terminator = "\r\n"
 # CSV 文件是否包含表头。
 # 如果为 true，则 lightning 会使用首行内容解析字段的对应关系。
 header = true
@@ -102,6 +104,8 @@ pd-addr = "${ip}:${port}"     # 集群 PD 的地址，Lightning 通过 PD 获取
 - delimiter 为空；
 - 每个字段不包含 CR (\\r）或 LF（\\n）。
 
+严格格式 `strict-format` 的 CSV 文件需要显式指定行结束符 `terminator`。
+
 如果你确认满足条件，可按如下配置开启 `strict-format` 模式以加快导入速度。
 
 ```toml

optimizer-hints.md

@@ -134,6 +134,10 @@ SELECT /*+ NO_MERGE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id;
 
 ### INL_JOIN(t1_name [, tl_name ...])
 
+> **注意：**
+>
+> 部分情况下 `INL_JOIN` Hint 可能无法生效，详情请参阅 [`INL_JOIN` Hint 不生效](#inl_join-hint-不生效)。
+
 `INL_JOIN(t1_name [, tl_name ...])` 提示优化器对指定表使用 Index Nested Loop Join 算法。这个算法可能会在某些场景更快，消耗更少系统资源，有的场景会更慢，消耗更多系统资源。对于外表经过 WHERE 条件过滤后结果集较小（小于 1 万行）的场景，可以尝试使用。例如：
 
 {{< copyable "sql" >}}
@@ -939,7 +943,74 @@ Warning 信息如下：
 
 在上面的示例中，你需要将 Hint 直接放在 `SELECT` 关键字之后。具体的语法规则参见 [Hint 语法](#语法)部分。
 
-### 排序规则不兼容导致 `INL_JOIN` Hint 不生效
+### `INL_JOIN` Hint 不生效
+
+#### 关联表的列上使用内置函数导致 `INL_JOIN` Hint 不生效
+
+在某些情况下，如果在关联表的列上使用了内置函数，优化器可能无法选择 `IndexJoin` 计划，导致 `INL_JOIN` Hint 也无法生效。
+
+例如，以下查询在关联表的列 `tname` 上使用了内置函数 `substr`：
+
+```sql
+CREATE TABLE t1 (id varchar(10) primary key, tname varchar(10));
+CREATE TABLE t2 (id varchar(10) primary key, tname varchar(10));
+EXPLAIN SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id=t2.id and SUBSTR(t1.tname,1,2)=SUBSTR(t2.tname,1,2);
+```
+
+查询计划输出结果如下：
+
+```sql
++------------------------------+----------+-----------+---------------+-----------------------------------------------------------------------+
+| id                           | estRows  | task      | access object | operator info                                                         |
++------------------------------+----------+-----------+---------------+-----------------------------------------------------------------------+
+| HashJoin_12                  | 12500.00 | root      |               | inner join, equal:[eq(test.t1.id, test.t2.id) eq(Column#5, Column#6)] |
+| ├─Projection_17(Build)       | 10000.00 | root      |               | test.t2.id, test.t2.tname, substr(test.t2.tname, 1, 2)->Column#6      |
+| │ └─TableReader_19           | 10000.00 | root      |               | data:TableFullScan_18                                                 |
+| │   └─TableFullScan_18       | 10000.00 | cop[tikv] | table:t2      | keep order:false, stats:pseudo                                        |
+| └─Projection_14(Probe)       | 10000.00 | root      |               | test.t1.id, test.t1.tname, substr(test.t1.tname, 1, 2)->Column#5      |
+|   └─TableReader_16           | 10000.00 | root      |               | data:TableFullScan_15                                                 |
+|     └─TableFullScan_15       | 10000.00 | cop[tikv] | table:t1      | keep order:false, stats:pseudo                                        |
++------------------------------+----------+-----------+---------------+-----------------------------------------------------------------------+
+7 rows in set, 1 warning (0.01 sec)
+```
+
+```sql
+SHOW WARNINGS;
+```
+
+```
++---------+------+------------------------------------------------------------------------------------+
+| Level   | Code | Message                                                                            |
++---------+------+------------------------------------------------------------------------------------+
+| Warning | 1815 | Optimizer Hint /*+ INL_JOIN(t1, t2) */ or /*+ TIDB_INLJ(t1, t2) */ is inapplicable |
++---------+------+------------------------------------------------------------------------------------+
+1 row in set (0.00 sec)
+```
+
+从该示例中可以看到，`INL_JOIN` Hint 没有生效。该问题的根本原因是优化器限制导致无法使用 `Projection` 或者 `Selection` 算子作为 `IndexJoin` 的探测 (Probe) 端。
+
+从 TiDB v8.0.0 起，你通过设置 [`tidb_enable_inl_join_inner_multi_pattern`](/system-variables.md#tidb_enable_inl_join_inner_multi_pattern-从-v700-版本开始引入) 为 `ON` 来避免该问题。
+
+```sql
+SET @@tidb_enable_inl_join_inner_multi_pattern=ON;
+Query OK, 0 rows affected (0.00 sec)
+
+EXPLAIN SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id=t2.id AND SUBSTR(t1.tname,1,2)=SUBSTR(t2.tname,1,2);
++------------------------------+--------------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------+
+| id                           | estRows      | task      | access object | operator info                                                                                                                              |
++------------------------------+--------------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------+
+| IndexJoin_18                 | 12500.00     | root      |               | inner join, inner:Projection_14, outer key:test.t1.id, inner key:test.t2.id, equal cond:eq(Column#5, Column#6), eq(test.t1.id, test.t2.id) |
+| ├─Projection_32(Build)       | 10000.00     | root      |               | test.t1.id, test.t1.tname, substr(test.t1.tname, 1, 2)->Column#5                                                                           |
+| │ └─TableReader_34           | 10000.00     | root      |               | data:TableFullScan_33                                                                                                                      |
+| │   └─TableFullScan_33       | 10000.00     | cop[tikv] | table:t1      | keep order:false, stats:pseudo                                                                                                             |
+| └─Projection_14(Probe)       | 100000000.00 | root      |               | test.t2.id, test.t2.tname, substr(test.t2.tname, 1, 2)->Column#6                                                                           |
+|   └─TableReader_13           | 10000.00     | root      |               | data:TableRangeScan_12                                                                                                                     |
+|     └─TableRangeScan_12      | 10000.00     | cop[tikv] | table:t2      | range: decided by [eq(test.t2.id, test.t1.id)], keep order:false, stats:pseudo                                                             |
++------------------------------+--------------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------+
+7 rows in set (0.00 sec)
+```
+
+#### 排序规则不兼容导致 `INL_JOIN` Hint 不生效
 
 如果两个表的 Join key 的排序规则不能兼容，将无法使用 IndexJoin 来执行查询。此时 [`INL_JOIN` Hint](#inl_joint1_name--tl_name-) 将无法生效。例如：
 
@@ -976,7 +1047,7 @@ SHOW WARNINGS;
 1 row in set (0.00 sec)
 ```
 
-### 连接顺序导致 `INL_JOIN` Hint 不生效
+#### 连接顺序导致 `INL_JOIN` Hint 不生效
 
 [`INL_JOIN(t1, t2)`](#inl_joint1_name--tl_name-) 或 `TIDB_INLJ(t1, t2)` 的语义是让 `t1` 和 `t2` 作为 `IndexJoin` 的内表与其他表进行连接，而不是直接将 `t1` 和 `t2` 进行 `IndexJoin` 连接。例如：
 

releases/release-7.5.1.md

@@ -43,6 +43,10 @@ TiDB 版本：7.5.1
     - 允许多个快速加索引 DDL 任务排队执行，而非回退为普通加索引任务 [#47758](https://github.com/pingcap/tidb/issues/47758) @[tangenta](https://github.com/tangenta)
     - 提升空表加索引的速度 [#49682](https://github.com/pingcap/tidb/issues/49682) @[zimulala](https://github.com/zimulala)
 
++ TiKV
+
+    - 改善慢节点检测的判定算法，提升算法检测的灵敏度，同时降低了算法对于热读写场景下的误判率 [#15909](https://github.com/tikv/tikv/issues/15909) @[LykxSassinator](https://github.com/LykxSassinator)
+
 + TiFlash
 
     - 改进 [RU (Request Unit)](/tidb-resource-control.md#什么是-request-unit-ru) 计算方法，以提高 RU 值的稳定性 [#8391](https://github.com/pingcap/tiflash/issues/8391) @[guo-shaoge](https://github.com/guo-shaoge)
@@ -159,6 +163,7 @@ TiDB 版本：7.5.1
     - 修复扩容时可能导致 DR Auto-Sync 的 joint state 超时问题 [#15817](https://github.com/tikv/tikv/issues/15817) @[Connor1996](https://github.com/Connor1996)
     - 修复 Resolved TS 可能被阻塞两小时的问题 [#11847](https://github.com/tikv/tikv/issues/11847) [#15520](https://github.com/tikv/tikv/issues/15520) [#39130](https://github.com/pingcap/tidb/issues/39130) @[overvenus](https://github.com/overvenus)
     - 修复 `cast_duration_as_time` 可能返回错误结果的问题 [#16211](https://github.com/tikv/tikv/issues/16211) @[gengliqi](https://github.com/gengliqi)
+    - 修复在某些异常场景下（如阻塞在 Disk I/O 操作上）TiKV 假死而影响可用性的问题 [#16368](https://github.com/tikv/tikv/issues/16368) @[LykxSassinator](https://github.com/LykxSassinator)
 
 + PD