Scalability and Performance
|
- TiKV supports Partitioned Raft KV storage engine (experimental) |
+ TiKV supports Partitioned Raft KV storage engine (experimental) |
TiKV introduces the Partitioned Raft KV storage engine, and each Region uses an independent RocksDB instance, which can easily expand the storage capacity of the cluster from TB to PB and provide more stable write latency and stronger scalability. |
- | TiKV supports batch aggregating data requests |
+ TiKV supports batch aggregating data requests |
This enhancement significantly reduces total RPCs in TiKV batch-get operations. In situations where data is highly dispersed and the gRPC thread pool has insufficient resources, batching coprocessor requests can improve performance by more than 50%. |
- | TiFlash supports Stale Read and compression exchange |
+ TiFlash supports Stale Read and compression exchange |
TiFlash supports the stale read feature, which can improve query performance in scenarios where real-time requirements are not restricted. TiFlash supports data compression to improve the efficiency of parallel data exchange, and the overall TPC-H performance improves by 10%, which can save more than 50% of the network usage. |
Reliability and availability
|
- Resource control (experimental) |
+ Resource control (experimental) |
Support resource management based on resource groups, which maps database users to the corresponding resource groups and sets quotas for each resource group based on actual needs. |
- | Historical SQL binding |
+ Historical SQL binding |
Support binding historical execution plans and quickly binding execution plans on TiDB Dashboard. |
SQL functionalities
|
- Foreign key (experimental) |
+ Foreign key (experimental) |
Support MySQL-compatible foreign key constraints to maintain data consistency and improve data quality. |
- | Multi-valued indexes (experimental) |
+ Multi-valued indexes (experimental) |
Introduce MySQL-compatible multi-valued indexes and enhance the JSON type to improve TiDB's compatibility with MySQL 8.0. |
DB operations and observability
|
- DM supports physical import (experimental) |
+ DM supports physical import (experimental) |
TiDB Data Migration (DM) integrates TiDB Lightning's physical import mode to improve the performance of full data migration, with performance being up to 10 times faster. |
@@ -79,17 +79,17 @@ In v6.6.0-DMR, the key new features and improvements are as follows:
* Support the distributed parallel execution framework for DDL operations (experimental) [#37125](https://github.com/pingcap/tidb/issues/37125) @[zimulala](https://github.com/zimulala)
- In previous versions, only one TiDB instance in the entire TiDB cluster was allowed to handle schema change tasks as a DDL owner. To further improve DDL concurrency for large table's DDL operations, TiDB v6.6.0 introduces the distributed parallel execution framework for DDL, through which all TiDB instances in the cluster can concurrently execute the `StateWriteReorganization` phase of the same task to speed up DDL execution. This feature is controlled by the system variable [`tidb_ddl_distribute_reorg`](https://docs.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660) and is currently only supported for `Add Index` operations.
+ In previous versions, only one TiDB instance in the entire TiDB cluster was allowed to handle schema change tasks as a DDL owner. To further improve DDL concurrency for large table's DDL operations, TiDB v6.6.0 introduces the distributed parallel execution framework for DDL, through which all TiDB instances in the cluster can concurrently execute the `StateWriteReorganization` phase of the same task to speed up DDL execution. This feature is controlled by the system variable [`tidb_ddl_distribute_reorg`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660) and is currently only supported for `Add Index` operations.
### Performance
* Support a stable wake-up model for pessimistic lock queues [#13298](https://github.com/tikv/tikv/issues/13298) @[MyonKeminta](https://github.com/MyonKeminta)
- If an application encounters frequent single-point pessimistic lock conflicts, the existing wake-up mechanism cannot guarantee the time for transactions to acquire locks, which causes high long-tail latency and even lock acquisition timeout. Starting from v6.6.0, you can enable a stable wake-up model for pessimistic locks by setting the value of the system variable [`tidb_pessimistic_txn_aggressive_locking`](https://docs.pingcap.com/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-new-in-v660) to `ON`. In this wake-up model, the wake-up sequence of a queue can be strictly controlled to avoid the waste of resources caused by invalid wake-ups. In scenarios with serious lock conflicts, the stable wake-up model can reduce long-tail latency and the P99 response time.
+ If an application encounters frequent single-point pessimistic lock conflicts, the existing wake-up mechanism cannot guarantee the time for transactions to acquire locks, which causes high long-tail latency and even lock acquisition timeout. Starting from v6.6.0, you can enable a stable wake-up model for pessimistic locks by setting the value of the system variable [`tidb_pessimistic_txn_aggressive_locking`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-new-in-v660) to `ON`. In this wake-up model, the wake-up sequence of a queue can be strictly controlled to avoid the waste of resources caused by invalid wake-ups. In scenarios with serious lock conflicts, the stable wake-up model can reduce long-tail latency and the P99 response time.
Tests indicate this reduces tail latency 40-60%.
- For more information, see [documentation](https://docs.pingcap.com/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-new-in-v660).
+ For more information, see [documentation](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-new-in-v660).
* Batch aggregate data requests [#39361](https://github.com/pingcap/tidb/issues/39361) @[cfzjywxk](https://github.com/cfzjywxk) @[you06](https://github.com/you06)
@@ -155,7 +155,7 @@ In v6.6.0-DMR, the key new features and improvements are as follows:
* Support dynamically managing the resource usage of DDL operations (experimental) [#38025](https://github.com/pingcap/tidb/issues/38025) @[hawkingrei](https://github.com/hawkingrei)
- TiDB v6.6.0 introduces resource management for DDL operations to reduce the impact of DDL changes on online applications by automatically controlling the CPU usage of these operations. This feature is effective only after the [DDL distributed parallel execution framework](https://docs.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660) is enabled.
+ TiDB v6.6.0 introduces resource management for DDL operations to reduce the impact of DDL changes on online applications by automatically controlling the CPU usage of these operations. This feature is effective only after the [DDL distributed parallel execution framework](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660) is enabled.
### Availability
@@ -364,13 +364,13 @@ In v6.6.0-DMR, the key new features and improvements are as follows:
| [`tidb_store_batch_size`](/system-variables.md#tidb_store_batch_size) | Modified | This variable controls the batch size of the Coprocessor Tasks of the `IndexLookUp` operator. `0` means to disable batch. Starting from v6.6.0, the default value is changed from `0` to `4`, which means 4 Coprocessor tasks will be batched into one task for each batch of requests. |
| [`mpp_exchange_compression_mode`](/system-variables.md#mpp_exchange_compression_mode-new-in-v660) | Newly added | This variable specifies the data compression mode of the MPP Exchange operator. It takes effect when TiDB selects the MPP execution plan with the version number `1`. The default value `UNSPECIFIED` means that TiDB automatically selects the `FAST` compression mode. |
| [`mpp_version`](/system-variables.md#mpp_version-new-in-v660) | Newly added | This variable specifies the version of the MPP execution plan. After a version is specified, TiDB selects the specified version of the MPP execution plan. The default value `UNSPECIFIED` means that TiDB automatically selects the latest version `1`. |
-| [`tidb_ddl_distribute_reorg`](https://docs.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660) | Newly added | This variable controls whether to enable distributed execution of the DDL reorg phase to accelerate this phase. The default value `OFF` means not to enable distributed execution of the DDL reorg phase by default. Currently, this variable takes effect only for `ADD INDEX`. |
+| [`tidb_ddl_distribute_reorg`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660) | Newly added | This variable controls whether to enable distributed execution of the DDL reorg phase to accelerate this phase. The default value `OFF` means not to enable distributed execution of the DDL reorg phase by default. Currently, this variable takes effect only for `ADD INDEX`. |
| [`tidb_enable_historical_stats_for_capture`](/system-variables.md#tidb_enable_historical_stats_for_capture) | Newly added | This variable controls whether the information captured by `PLAN REPLAYER CAPTURE` includes historical statistics by default. The default value `OFF` means that historical statistics are not included by default. |
| [`tidb_enable_plan_cache_for_param_limit`](/system-variables.md#tidb_enable_plan_cache_for_param_limit-new-in-v660) | Newly added | This variable controls whether Prepared Plan Cache caches execution plans that contain `COUNT` after `Limit`. The default value is `ON`, which means Prepared Plan Cache supports caching such execution plans. Note that Prepared Plan Cache does not support caching execution plans with a `COUNT` condition that counts a number greater than 10000. |
| [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) | Newly added | This variable controls whether to enable the resource control feature. The default value is `OFF`. When this variable is set to `ON`, the TiDB cluster supports resource isolation of applications based on resource groups. |
| [`tidb_historical_stats_duration`](/system-variables.md#tidb_historical_stats_duration-new-in-v660) | Newly added | This variable controls how long the historical statistics are retained in storage. The default value is 7 days. |
| [`tidb_index_join_double_read_penalty_cost_rate`](/system-variables.md#tidb_index_join_double_read_penalty_cost_rate-new-in-v660) | Newly added | This variable controls whether to add some penalty cost to the selection of index join. The default value `0` means that this feature is disabled by default. |
-| [`tidb_pessimistic_txn_aggressive_locking`](https://docs.pingcap.com/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-new-in-v660) | Newly added | This variable controls whether to use enhanced pessimistic locking wake-up model for pessimistic transactions. The default value `OFF` means not to use such a wake-up model for pessimistic transactions by default. |
+| [`tidb_pessimistic_txn_aggressive_locking`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-new-in-v660) | Newly added | This variable controls whether to use enhanced pessimistic locking wake-up model for pessimistic transactions. The default value `OFF` means not to use such a wake-up model for pessimistic transactions by default. |
| [`tidb_stmt_summary_enable_persistent`](/system-variables.md#tidb_stmt_summary_enable_persistent-new-in-v660) | Newly added | This variable is read-only. It controls whether to enable [statements summary persistence](/statement-summary-tables.md#persist-statements-summary). The value of this variable is the same as that of the configuration item [`tidb_stmt_summary_enable_persistent`](/tidb-configuration-file.md#tidb_stmt_summary_enable_persistent-new-in-v660). |
| [`tidb_stmt_summary_filename`](/system-variables.md#tidb_stmt_summary_filename-new-in-v660) | Newly added | This variable is read-only. It specifies the file to which persistent data is written when [statements summary persistence](/statement-summary-tables.md#persist-statements-summary) is enabled. The value of this variable is the same as that of the configuration item [`tidb_stmt_summary_filename`](/tidb-configuration-file.md#tidb_stmt_summary_filename-new-in-v660). |
| [`tidb_stmt_summary_file_max_backups`](/system-variables.md#tidb_stmt_summary_file_max_backups-new-in-v660) | Newly added | This variable is read-only. It specifies the maximum number of data files that can be persisted when [statements summary persistence](/statement-summary-tables.md#persist-statements-summary) is enabled. The value of this variable is the same as that of the configuration item [`tidb_stmt_summary_file_max_backups`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_backups-new-in-v660). |
diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md
index 603c9dc39cc30..2f2d13327d426 100644
--- a/releases/release-7.0.0.md
+++ b/releases/release-7.0.0.md
@@ -9,7 +9,7 @@ Release date: March 30, 2023
TiDB version: 7.0.0-[DMR](/releases/versioning.md#development-milestone-releases)
-Quick access: [Quick start](https://docs.pingcap.com/tidb/v7.0/quick-start-with-tidb)
+Quick access: [Quick start](https://docs-archive.pingcap.com/tidb/v7.0/quick-start-with-tidb)
In v7.0.0-DMR, the key new features and improvements are as follows:
@@ -24,11 +24,11 @@ In v7.0.0-DMR, the key new features and improvements are as follows:
Scalability and Performance
|
- Session level non-prepared SQL plan cache (experimental) |
+ Session level non-prepared SQL plan cache (experimental) |
Support automatically reusing plan cache at the session level to reduce compilation and shorten the query time for the same SQL patterns without manually setting prepare statements in advance. |
- | TiFlash supports the disaggregated storage and compute architecture and S3 shared storage (experimental) |
+ TiFlash supports the disaggregated storage and compute architecture and S3 shared storage (experimental) |
TiFlash introduces a cloud-native architecture as an option:
- Disaggregates TiFlash's compute and storage, which is a milestone for elastic HTAP resource utilization.
@@ -38,29 +38,29 @@ In v7.0.0-DMR, the key new features and improvements are as follows:
|
Reliability and Availability
|
- Resource control enhancement (experimental) |
+ Resource control enhancement (experimental) |
Support using resource groups to allocate and isolate resources for various applications or workloads within one cluster. In this release, TiDB adds support for different resource binding modes (user, session, and statement levels) and user-defined priorities. Additionally, you can also use commands to perform resource calibration (estimation for the whole resource amount). |
- | TiFlash supports spill to disk |
+ TiFlash supports spill to disk |
TiFlash supports intermediate result spill to disk to mitigate OOMs in data-intensive operations such as aggregations, sorts, and hash joins. |
| SQL |
- Row-level TTL (GA) |
+ Row-level TTL (GA) |
Support managing database size and improve performance by automatically expiring data of a certain age. |
- Reorganize LIST/RANGE partition |
+ Reorganize LIST/RANGE partition |
The REORGANIZE PARTITION statement can be used for merging adjacent partitions or splitting one partition into many, which provides better usability of partitioned tables. |
DB Operations and Observability
|
- TiDB enhances the functionalities of LOAD DATA statements (experimental) |
+ TiDB enhances the functionalities of LOAD DATA statements (experimental) |
TiDB enhances the functionalities of LOAD DATA SQL statements, such as supporting data import from S3/GCS.
|
- | TiCDC supports object storage sink (GA) |
+ TiCDC supports object storage sink (GA) |
TiCDC supports replicating row change events to object storage services, including Amazon S3, GCS, Azure Blob Storage, and NFS.
|
diff --git a/releases/release-7.3.0.md b/releases/release-7.3.0.md
index abf376bd8a6c1..eda3ce505c1df 100644
--- a/releases/release-7.3.0.md
+++ b/releases/release-7.3.0.md
@@ -9,7 +9,7 @@ Release date: August 14, 2023
TiDB version: 7.3.0
-Quick access: [Quick start](https://docs.pingcap.com/tidb/v7.3/quick-start-with-tidb)
+Quick access: [Quick start](https://docs-archive.pingcap.com/tidb/v7.3/quick-start-with-tidb)
7.3.0 introduces the following major features. In addition to that, 7.3.0 also includes a series of enhancements (described in the [Feature details](#feature-details) section) to query stability in TiDB server and TiFlash. These enhancements are more miscellaneous in nature and not user-facing so they are not included in the following table.
@@ -24,28 +24,28 @@ Quick access: [Quick start](https://docs.pingcap.com/tidb/v7.3/quick-start-with-
| Scalability and Performance |
- TiDB Lightning supports Partitioned Raft KV (experimental) |
+ TiDB Lightning supports Partitioned Raft KV (experimental) |
TiDB Lightning now supports the new Partitioned Raft KV architecture, as part of the near-term GA of the architecture.
|
| Reliability and Availability |
- Add automatic conflict detection and resolution on data imports |
+ Add automatic conflict detection and resolution on data imports |
The TiDB Lightning Physical Import Mode supports a new version of conflict detection, which implements the semantics of replacing (replace) or ignoring (ignore) conflict data when encountering conflicts. It automatically handles conflict data for you while improving the performance of conflict resolution. |
- | Manual management of runaway queries (experimental) |
+ Manual management of runaway queries (experimental) |
Queries might take longer than you expect. With the new watch list of resource groups, you can now manage queries more effectively and either deprioritize or kill them. Allowing operators to mark target queries by exact SQL text, SQL digest, or plan digest and deal with the queries at a resource group level, this feature gives you much more control over the potential impact of unexpected large queries on a cluster. |
| SQL |
- Enhance operator control over query stability by adding more optimizer hints to the query planner |
+ Enhance operator control over query stability by adding more optimizer hints to the query planner |
Added hints: NO_INDEX_JOIN(), NO_MERGE_JOIN(), NO_INDEX_MERGE_JOIN(), NO_HASH_JOIN(), NO_INDEX_HASH_JOIN()
|
| DB Operations and Observability |
- Show the progress of statistics collection tasks |
+ Show the progress of statistics collection tasks |
Support viewing the progress of ANALYZE tasks using the SHOW ANALYZE STATUS statement or through the mysql.analyze_jobs system table. |
@@ -224,7 +224,7 @@ Quick access: [Quick start](https://docs.pingcap.com/tidb/v7.3/quick-start-with-
* TiDB
- The [`Fast Analyze`](/system-variables.md#tidb_enable_fast_analyze) feature (experimental) for statistics will be deprecated in v7.5.0.
- - The [incremental collection](https://docs.pingcap.com/tidb/v7.3/statistics#incremental-collection) feature for statistics will be deprecated in v7.5.0.
+ - The [incremental collection](https://docs-archive.pingcap.com/tidb/v7.3/statistics#incremental-collection) feature for statistics will be deprecated in v7.5.0.
## Improvements
diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md
index 8b09b93c7370c..d163c1c4ab84a 100644
--- a/releases/release-7.5.0.md
+++ b/releases/release-7.5.0.md
@@ -199,7 +199,7 @@ Starting from v7.5.0, the following contents are removed from the `TiDB-communit
## Deprecated features
-* [Mydumper](https://docs.pingcap.com/tidb/v4.0/mydumper-overview) is deprecated in v7.5.0 and most of its features have been replaced by [Dumpling](/dumpling-overview.md). It is strongly recommended that you use Dumpling instead of Mydumper.
+* [Mydumper](https://docs-archive.pingcap.com/tidb/v4.0/mydumper-overview) is deprecated in v7.5.0 and most of its features have been replaced by [Dumpling](/dumpling-overview.md). It is strongly recommended that you use Dumpling instead of Mydumper.
* TiKV-importer is deprecated in v7.5.0. It is strongly recommended that you use the [Physical Import Mode of TiDB Lightning](/tidb-lightning/tidb-lightning-physical-import-mode.md) as an alternative.
@@ -207,7 +207,7 @@ Starting from v7.5.0, the following contents are removed from the `TiDB-communit
* The [`Fast Analyze`](/system-variables.md#tidb_enable_fast_analyze) feature (experimental) for statistics is deprecated in v7.5.0.
-* The [incremental collection](https://docs.pingcap.com/tidb/v7.4/statistics#incremental-collection) feature (experimental) for statistics is deprecated in v7.5.0.
+* The [incremental collection](https://docs-archive.pingcap.com/tidb/v7.4/statistics#incremental-collection) feature (experimental) for statistics is deprecated in v7.5.0.
## Improvements
diff --git a/releases/release-8.0.0.md b/releases/release-8.0.0.md
index c82bd5d0bef41..1413e4752fa7b 100644
--- a/releases/release-8.0.0.md
+++ b/releases/release-8.0.0.md
@@ -9,7 +9,7 @@ Release date: March 29, 2024
TiDB version: 8.0.0
-Quick access: [Quick start](https://docs.pingcap.com/tidb/v8.0/quick-start-with-tidb)
+Quick access: [Quick start](https://docs-archive.pingcap.com/tidb/v8.0/quick-start-with-tidb)
8.0.0 introduces the following key features and improvements:
@@ -24,33 +24,33 @@ Quick access: [Quick start](https://docs.pingcap.com/tidb/v8.0/quick-start-with-
| Scalability and Performance |
- Disaggregation of PD to improve scalability (experimental) |
+ Disaggregation of PD to improve scalability (experimental) |
Placement Driver (PD) contains multiple critical modules to ensure the normal operation of TiDB clusters. As the workload of a cluster increases, the resource consumption of each module in PD also increases, causing mutual interference between these modules and ultimately affecting the overall service quality of the cluster. Starting from v8.0.0, TiDB addresses this issue by splitting the TSO and scheduling modules in PD into independently deployable microservices. This can significantly reduce the mutual interference between modules as the cluster scales. With this architecture, much larger clusters with much larger workloads are now possible. |
- | Bulk DML for much larger transactions (experimental) |
+ Bulk DML for much larger transactions (experimental) |
Large batch DML jobs, such as extensive cleanup jobs, joins, or aggregations, can consume a significant amount of memory and have previously been limited at very large scales. Bulk DML (tidb_dml_type = "bulk") is a new DML type for handling large batch DML tasks more efficiently while providing transaction guarantees and mitigating OOM issues. This feature differs from import, load, and restore operations when used for data loading. |
- | Acceleration of cluster snapshot restore speed (GA) |
+ Acceleration of cluster snapshot restore speed (GA) |
With this feature, BR can fully leverage the scale advantage of a cluster, enabling all TiKV nodes in the cluster to participate in the preparation step of data restores. This feature can significantly improve the restore speed of large datasets in large-scale clusters. Real-world tests show that this feature can saturate the download bandwidth, with the download speed improving by 8 to 10 times, and the end-to-end restore speed improving by approximately 1.5 to 3 times. |
| Enhance the stability of caching the schema information when there is a massive number of tables (experimental) |
- SaaS companies using TiDB as the system of record for their multi-tenant applications often need to store a substantial number of tables. In previous versions, handling table counts in the order of a million or more was feasible, but it had the potential to degrade the overall user experience. TiDB v8.0.0 improves the situation by implementing a priority queue for auto analyze, making the process less rigid and enhancing stability across a wider array of tables. |
+ SaaS companies using TiDB as the system of record for their multi-tenant applications often need to store a substantial number of tables. In previous versions, handling table counts in the order of a million or more was feasible, but it had the potential to degrade the overall user experience. TiDB v8.0.0 improves the situation by implementing a priority queue for auto analyze, making the process less rigid and enhancing stability across a wider array of tables. |
| DB Operations and Observability |
Support monitoring index usage statistics |
- Proper index design is a crucial prerequisite to maintaining database performance. TiDB v8.0.0 introduces the INFORMATION_SCHEMA.TIDB_INDEX_USAGE table and the sys.schema_unused_indexes view to provide usage statistics of indexes. This feature helps you assess the efficiency of indexes in the database and optimize the index design. |
+ Proper index design is a crucial prerequisite to maintaining database performance. TiDB v8.0.0 introduces the INFORMATION_SCHEMA.TIDB_INDEX_USAGE table and the sys.schema_unused_indexes view to provide usage statistics of indexes. This feature helps you assess the efficiency of indexes in the database and optimize the index design. |
| Data Migration |
- TiCDC adds support for the Simple protocol |
+ TiCDC adds support for the Simple protocol |
TiCDC introduces a new protocol, the Simple protocol. This protocol provides in-band schema tracking capabilities by embedding table schema information in DDL and BOOTSTRAP events. |
- | TiCDC adds support for the Debezium format protocol |
+ TiCDC adds support for the Debezium format protocol |
TiCDC introduces a new protocol, the Debezium protocol. TiCDC can now publish data change events to a Kafka sink using a protocol that generates Debezium style messages. |
diff --git a/releases/release-8.2.0.md b/releases/release-8.2.0.md
index a6b47a2cf8d0b..37a7b280b567e 100644
--- a/releases/release-8.2.0.md
+++ b/releases/release-8.2.0.md
@@ -9,7 +9,7 @@ Release date: July 11, 2024
TiDB version: 8.2.0
-Quick access: [Quick start](https://docs.pingcap.com/tidb/v8.2/quick-start-with-tidb)
+Quick access: [Quick start](https://docs-archive.pingcap.com/tidb/v8.2/quick-start-with-tidb)
8.2.0 introduces the following key features and improvements:
@@ -24,20 +24,20 @@ Quick access: [Quick start](https://docs.pingcap.com/tidb/v8.2/quick-start-with-
| Reliability and Availability |
- TiProxy supports multiple load balancing policies |
+ TiProxy supports multiple load balancing policies |
In TiDB v8.2.0, TiProxy evaluates and ranks TiDB nodes based on various dimensions, such as status, connection counts, health, memory, CPU, and location. According to the load balancing policy specified in the policy configuration item, TiProxy dynamically selects the optimal TiDB node to execute database operations. This optimizes overall resource usage, improves cluster performance, and increases throughput. |
- | The parallel HashAgg algorithm of TiDB supports disk spill (GA) |
+ The parallel HashAgg algorithm of TiDB supports disk spill (GA) |
HashAgg is a widely used aggregation operator in TiDB for efficiently aggregating rows with the same field values. TiDB v8.0.0 introduces parallel HashAgg as an experimental feature to further enhance processing speed. When memory resources are insufficient, parallel HashAgg spills temporary sorted data to disk, avoiding potential OOM risks caused by excessive memory usage. This improves query performance while maintaining node stability. In v8.2.0, this feature becomes generally available (GA) and is enabled by default, enabling you to safely configure the concurrency of parallel HashAgg using tidb_executor_concurrency. |
- | Improve statistics loading efficiency by up to 10 times |
+ Improve statistics loading efficiency by up to 10 times |
For clusters with a large number of tables and partitions, such as SaaS or PaaS services, improvement in statistics loading efficiency can solve the problem of slow startup of TiDB instances, and increase the success rate of dynamic loading of statistics. This improvement reduces performance rollbacks caused by statistics loading failures and improves cluster stability. |
| DB Operations and Observability |
- Introduce privilege control of switching resource groups |
+ Introduce privilege control of switching resource groups |
As resource control is widely used, the privilege control of switching resource groups can prevent database users from abusing resources, strengthen administrators' protection of overall resource usage, and improve cluster stability. |
diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md
index 71a22c163fdf8..e9cfb2537357a 100644
--- a/releases/release-8.4.0.md
+++ b/releases/release-8.4.0.md
@@ -9,7 +9,7 @@ Release date: November 11, 2024
TiDB version: 8.4.0
-Quick access: [Quick start](https://docs.pingcap.com/tidb/v8.4/quick-start-with-tidb)
+Quick access: [Quick start](https://docs-archive.pingcap.com/tidb/v8.4/quick-start-with-tidb)
8.4.0 introduces the following key features and improvements:
@@ -24,36 +24,36 @@ Quick access: [Quick start](https://docs.pingcap.com/tidb/v8.4/quick-start-with-
| Scalability and Performance |
- Instance-level execution plan cache (experimental) |
+ Instance-level execution plan cache (experimental) |
Instance-level plan cache allows all sessions within the same TiDB instance to share the plan cache. Compared with session-level plan cache, this feature reduces SQL compilation time by caching more execution plans in memory, decreasing overall SQL execution time. It improves OLTP performance and throughput while providing better control over memory usage and enhancing database stability. |
- | Global indexes for partitioned tables (GA) |
+ Global indexes for partitioned tables (GA) |
Global indexes can effectively improve the efficiency of retrieving non-partitioned columns, and remove the restriction that a unique key must contain the partition key. This feature extends the usage scenarios of TiDB partitioned tables, and avoids some of the application modification work required for data migration. |
- | Parallel mode for TSO requests |
+ Parallel mode for TSO requests |
In high-concurrency scenarios, you can use this feature to reduce the wait time for retrieving TSO and improve the cluster throughput. |
- | Improve query performance for cached tables |
+ Improve query performance for cached tables |
Improve query performance for index scanning on cached tables, with improvements of up to 5.4 times in some scenarios. For high-speed queries on small tables, using cached tables can significantly enhance overall performance. |
| Reliability and Availability |
- Support more triggers for runaway queries, and support switching resource groups |
+ Support more triggers for runaway queries, and support switching resource groups |
Runaway Queries offer an effective way to mitigate the impact of unexpected SQL performance issues on systems. TiDB v8.4.0 introduces the number of keys processed by the Coprocessor (PROCESSED_KEYS) and request units (RU) as identifying conditions, and puts identified queries into the specified resource group for more precise identification and control of runaway queries. |
- | Support setting the maximum limit on resource usage for background tasks of resource control |
+ Support setting the maximum limit on resource usage for background tasks of resource control |
By setting a maximum percentage limit on background tasks of resource control, you can control their resource consumption based on the needs of different application systems. This keeps background task consumption at a low level and ensures the quality of online services. |
- | TiProxy supports traffic capture and replay (experimental) |
+ TiProxy supports traffic capture and replay (experimental) |
Use TiProxy to capture real workloads from TiDB production clusters before major operations such as cluster upgrades, migrations, or deployment changes. Replay these workloads on target test clusters to validate performance and ensure successful changes. |
- | Concurrent automatic statistics collection |
+ Concurrent automatic statistics collection |
Introduce the system variable tidb_auto_analyze_concurrency to control the number of concurrent auto-analyze operations within a TiDB cluster. TiDB automatically determines the concurrency of scanning tasks based on node scale and hardware specifications. This improves statistics collection efficiency by fully utilizing system resources, reduces manual tuning, and ensures stable cluster performance. |
@@ -63,20 +63,20 @@ Quick access: [Quick start](https://docs.pingcap.com/tidb/v8.4/quick-start-with-
| DB Operations and Observability |
- Display TiKV and TiDB CPU times in memory tables |
+ Display TiKV and TiDB CPU times in memory tables |
The CPU time is now integrated into a system table, displayed alongside other metrics for sessions or SQL, letting you observe high CPU consumption operations from multiple perspectives, and improving diagnostic efficiency. This is especially useful for diagnosing scenarios such as CPU spikes in instances or read/write hotspots in clusters. |
- | Support viewing aggregated TiKV CPU time by table or database |
+ Support viewing aggregated TiKV CPU time by table or database |
When hotspot issues are not caused by individual SQL statements, using the aggregated CPU time by table or database level in Top SQL can help you quickly identify the tables or applications responsible for the hotspots, significantly improving the efficiency of diagnosing hotspot and CPU consumption issues. |
- | Support backing up TiKV instances with IMDSv2 service enabled |
+ Support backing up TiKV instances with IMDSv2 service enabled |
AWS EC2 now uses IMDSv2 as the default metadata service. TiDB supports backing up data from TiKV instances that have IMDSv2 enabled, helping you run TiDB clusters more effectively in public cloud services. |
| Security |
- Client-side encryption of log backup data (experimental) |
+ Client-side encryption of log backup data (experimental) |
Before uploading log backup data to your backup storage, you can encrypt the backup data to ensure its security during storage and transmission. |
diff --git a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md
index eee76322b5c3d..3b05d95cf912e 100644
--- a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md
+++ b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md
@@ -24,7 +24,7 @@ max-backups = 14
check-requirements = true
[mydumper]
-# The local data source directory or the URI of the external storage. For more information about the URI of the external storage, see https://docs.pingcap.com/tidb/v6.6/backup-and-restore-storages#uri-format.
+# The local data source directory or the URI of the external storage. For more information about the URI of the external storage, see https://docs.pingcap.com/tidb/stable/backup-and-restore-storages/#uri-format.
data-source-dir = "/data/my_database"
[tikv-importer]
diff --git a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md
index 6caf6e4357817..a93a56c4e5f21 100644
--- a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md
+++ b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md
@@ -26,7 +26,7 @@ max-backups = 14
check-requirements = true
[mydumper]
-# The local data source directory or the URI of the external storage. For more information about the URI of the external storage, see https://docs.pingcap.com/tidb/v6.6/backup-and-restore-storages#uri-format.
+# The local data source directory or the URI of the external storage. For more information about the URI of the external storage, see https://docs.pingcap.com/tidb/stable/backup-and-restore-storages/#uri-format.
data-source-dir = "/data/my_database"
[conflict]