From b50c5730a050549bc4043dca7a49134530d6b855 Mon Sep 17 00:00:00 2001 From: qiancai Date: Thu, 6 Aug 2026 17:46:17 +0800 Subject: [PATCH 01/15] Create tidb-x-cloud.202603.1-reused.md --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 138 +++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 tidb-cloud/releases/tidb-x-cloud.202603.1.md diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md new file mode 100644 index 0000000000000..7a09baea93da0 --- /dev/null +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -0,0 +1,138 @@ +--- +title: TiDB-X-CLOUD.202603.1 Release Notes +summary: Learn about the features for the TiDB-X-CLOUD.202603.1 kernel. +--- + +# TiDB-X-CLOUD.202603.1 Release Notes + +**Release date**: April 28, 2026 + +**Applicable TiDB Cloud plan**: {{{ .premium }}} + +**TiDB X kernel version**: `TiDB-X-CLOUD.202603.1` + +{{{ .premium }}} is available in public preview starting April 28, 2026, using the `TiDB-X-CLOUD.202603.1` kernel. + +In `TiDB-X-CLOUD.202603.1`: + +- `202603` indicates that the baseline code branch of this kernel version was created in March 2026, which is different from the release date. +- `1` indicates that it is the first patch release built from the `TiDB-X-CLOUD.202603` baseline branch. + +## Features + +### Performance + +* Introduce significant performance improvements for certain lossy DDL operations (such as `BIGINT → INT` and `CHAR(120) → VARCHAR(60)`): when no data truncation occurs, the execution time of these operations can be reduced from hours to minutes, seconds, or even milliseconds, delivering performance gains ranging from tens to hundreds of thousands of times [#63366](https://github.com/pingcap/tidb/issues/63366) @[wjhuang2016](https://github.com/wjhuang2016), @[tangenta](https://github.com/tangenta), @[fzzf678](https://github.com/fzzf678) + + The optimization strategies are as follows: + + - In strict SQL mode, TiDB pre-checks for potential data truncation risks during type conversion. + - If no data truncation risk is detected, TiDB updates only the metadata and avoids index rebuilding whenever possible. + - If index rebuilding is required, TiDB uses a more efficient ingest process to significantly improve index rebuild performance. + + The following table shows example performance improvements based on benchmark tests on a table with 114 GiB of data and 600 million rows. The test cluster consists of 3 TiDB nodes, 6 TiKV nodes, and 1 PD node. All nodes are configured with 16 CPU cores and 32 GiB of memory. + + | Scenario | Operation type | Before optimization | After optimization | Performance improvement | + |----------|----------------|---------------------|--------------------|--------------------------| + | Non-indexed column | `BIGINT → INT` | 2 hours 34 minutes | 1 minute 5 seconds | 142× faster | + | Indexed column | `BIGINT → INT` | 6 hours 25 minutes | 0.05 seconds | 460,000× faster | + | Indexed column | `CHAR(120) → VARCHAR(60)` | 7 hours 16 minutes | 12 minutes 56 seconds | 34× faster | + + Note that the preceding test results are based on the condition that no data truncation occurs during the DDL execution. The optimizations do not apply to conversions between signed and unsigned integer types, conversions between character sets, or tables with TiFlash replicas. + + For more information, see [documentation](/sql-statements/sql-statement-modify-column.md). + +* Support pushing index lookups down to TiKV to improve query performance [#62575](https://github.com/pingcap/tidb/issues/62575) @[lcwangchao](https://github.com/lcwangchao) + + Now TiDB supports using [optimizer hints](/optimizer-hints.md) to push the `IndexLookUp` operator down to TiKV nodes. This reduces the number of remote procedure calls (RPCs) and can improve query performance. The actual performance improvement varies depending on the specific workload and requires testing for verification. + + To explicitly instruct the optimizer to push index lookups down to TiKV for a specific table, you can use the [`INDEX_LOOKUP_PUSHDOWN(t1_name, idx1_name [, idx2_name ...])`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855) hint. It is recommended to combine this hint with the table's AFFINITY attribute. For example, set `AFFINITY="table"` for regular tables and `AFFINITY="partition"` for partitioned tables. + + To disable index lookup pushdown to TiKV for a specific table, use the [`NO_INDEX_LOOKUP_PUSHDOWN(t1_name)`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#no_index_lookup_pushdownt1_name-new-in-v855) hint. + + For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855). + +* Support table-level data affinity to improve query performance (experimental) [#9764](https://github.com/tikv/pd/issues/9764) @[lhy1024](https://github.com/lhy1024) + + Now you can configure the `AFFINITY` table option as `table` or `partition` when creating or altering a table. When this option is enabled, PD groups Regions that belong to the same table or the same partition into a single affinity group. During scheduling, PD prioritizes placing the Leaders and Voter replicas of these Regions on the same subset of a few TiKV nodes. In this scenario, by using the [`INDEX_LOOKUP_PUSHDOWN`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855) hint in queries, you can explicitly instruct the optimizer to push index lookups down to TiKV, reducing the latency caused by cross-node scattered queries and improving query performance. + + Note that this feature is currently experimental and is disabled by default. To enable it, set the PD configuration item [`schedule.affinity-schedule-limit`](https://docs.pingcap.com/tidb/v8.5/pd-configuration-file#affinity-schedule-limit-new-in-v855) to a value greater than `0`. This configuration item controls the maximum number of affinity scheduling tasks that PD can perform concurrently. + + For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/table-affinity). + +* Foreign key checks now support shared locks [#66154](https://github.com/pingcap/tidb/issues/66154) @[you06](https://github.com/you06) + + In pessimistic transactions, when you run `INSERT` or `UPDATE` on a child table with foreign key constraints, foreign key checks lock the corresponding parent table rows with exclusive locks by default. In high-concurrency write scenarios on the child table, if many transactions access the same parent table rows, severe lock contention can occur. + + Now you can set the [`tidb_foreign_key_check_in_shared_lock`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_foreign_key_check_in_shared_lock-new-in-v856) system variable to `ON` to let foreign key checks use shared locks on the parent table, thereby reducing lock contention and improving concurrent write performance on the child table. + + For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/foreign-key#locking). + +### Stability + +* The feature of setting the maximum limit on resource usage for background tasks of resource control becomes generally available (GA) [#56019](https://github.com/pingcap/tidb/issues/56019) @[glorv](https://github.com/glorv) + + TiDB resource control can identify and lower the priority of background tasks. In certain scenarios, you might want to limit the resource consumption of background tasks, even when resources are available. Starting from v8.4.0, you can use the `UTILIZATION_LIMIT` parameter to set the maximum percentage of resources that background tasks can consume. Each node will keep the resource usage of all background tasks below this percentage. This feature enables precise control over resource consumption for background tasks, further enhancing cluster stability. + + Now this feature is generally available (GA). + + For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/tidb-resource-control-background-tasks). + +### Observability + +* Support defining multi-dimensional, fine-grained trigger rules for slow query logs [#62959](https://github.com/pingcap/tidb/issues/62959), [#64010](https://github.com/pingcap/tidb/issues/64010) @[zimulala](https://github.com/zimulala) + + Before v8.5.6, the main way to identify slow queries in TiDB is to set the [`tidb_slow_log_threshold`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_threshold) system variable. This mechanism provides only coarse-grained control over slow query log triggering because it applies globally at the instance level and does not support fine-grained control at the session or SQL level. In addition, it supports only one trigger condition, execution time (`Query_time`), which cannot meet the need to capture slow query logs more precisely in complex scenarios. + + Starting from v8.5.6, TiDB enhances slow query log control. You can use the [`tidb_slow_log_rules`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_rules-new-in-v856) system variable to define multi-dimensional slow query log output rules at the instance, session, and SQL levels, based on conditions such as `Query_time`, `Digest`, `Mem_max`, and `KV_total`. You can use [`tidb_slow_log_max_per_sec`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_max_per_sec-new-in-v856) to limit the number of log entries written per second, and use the [`WRITE_SLOW_LOG`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints) hint to force slow query logging for specific SQL statements. This enables more flexible and fine-grained control over slow query logs. + + For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/identify-slow-queries). + +### SQL + +* Support using table aliases in the `FOR UPDATE OF` clause [#63035](https://github.com/pingcap/tidb/issues/63035) @[cryo-zd](https://github.com/cryo-zd) + + Before this release, when a `SELECT ... FOR UPDATE OF ` statement references a table alias in the locking clause, TiDB might fail to resolve the alias correctly and return the `table not exists` error even if the alias is valid. + + Now TiDB supports using table aliases in the `FOR UPDATE OF` clause. TiDB can now correctly resolve locking targets from the `FROM` clause, including aliased tables, ensuring that row locks take effect as expected. This improves MySQL compatibility and makes `SELECT ... FOR UPDATE OF` statements more stable and reliable in queries that use table aliases. + + For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/sql-statement-select). + +* Support partial indexes to reduce index storage and DML maintenance overhead [#62664](https://github.com/pingcap/tidb/issues/62664) [#62761](https://github.com/pingcap/tidb/issues/62761) [#62758](https://github.com/pingcap/tidb/issues/62758) [#63447](https://github.com/pingcap/tidb/issues/63447) [#64344](https://github.com/pingcap/tidb/issues/64344) @[YangKeao](https://github.com/YangKeao) @[winoros](https://github.com/winoros) @[wjhuang2016](https://github.com/wjhuang2016) + + Now TiDB supports partial indexes, which index only rows that satisfy a predicate defined in the index `WHERE` clause. You can create a partial index using `CREATE INDEX ... WHERE ...`, `ALTER TABLE ... ADD INDEX ... WHERE ...`, or an index definition in `CREATE TABLE`. + + Partial indexes are useful when you frequently query a subset of rows based on specific conditions or need unique constraints that apply only under specific conditions. Because rows outside the predicate are not written to the index, partial indexes help reduce index storage and can lower index maintenance overhead during `INSERT`, `UPDATE`, and `DELETE` operations. + + To use partial indexes effectively, define a predicate that matches the filters in your common queries. TiDB selects a partial index only when the query predicates match or imply the partial index predicate. Currently, partial index predicates support basic comparison operators (`=`, `!=`, `<`, `<=`, `>`, `>=`), `IS NULL`, `IS NOT NULL`, and `IN` predicates with constant values. + + For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/sql-statement-create-index#partial-indexes). + +## Compatibility changes + +### MySQL compatibility + +* Dumpling supports exporting data from MySQL 8.4 by adapting to the updated MySQL binary log naming. [#53082](https://github.com/pingcap/tidb/issues/53082) @[dveeden](https://github.com/dveeden) + +* Support parsing the `LATERAL` syntax for derived tables to improve MySQL 8.0 compatibility, including comma joins, `CROSS JOIN LATERAL`, and `INNER JOIN LATERAL` + + Currently, TiDB only supports parsing [the `LATERAL` derived table syntax](https://docs.pingcap.com/tidb/v8.5/lateral-derived-tables) and does not support executing queries that use this syntax. If you attempt to execute such a query, TiDB returns an error. You can track the progress of full execution capability for this feature in issue [#40328](https://github.com/pingcap/tidb/issues/40328). + +## Improvements + +- Enhance the parsing mechanism for Parquet files to improve the import performance of Parquet-formatted data [#62906](https://github.com/pingcap/tidb/issues/62906) @[joechenrh](https://github.com/joechenrh) +- Change the default value of `tidb_analyze_column_options` to `ALL` to collect statistics for all columns by default [#64992](https://github.com/pingcap/tidb/issues/64992) @[0xPoe](https://github.com/0xPoe) +- Optimize the execution logic of the `IndexHashJoin` operator by using incremental processing in specific JOIN scenarios to avoid loading large amounts of data at once, significantly reducing memory usage and improving performance [#63303](https://github.com/pingcap/tidb/issues/63303) @[ChangRui-Ryan](https://github.com/ChangRui-Ryan) +- Improve slow query log readability by outputting non-printable prepared statement arguments as hexadecimal values [#65383](https://github.com/pingcap/tidb/issues/65383) @[dveeden](https://github.com/dveeden) +- Improve slow query observability by logging client connection attributes in the slow query log and making them queryable in `INFORMATION_SCHEMA.SLOW_QUERY` and `INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY`; `performance_schema_session_connect_attrs_size` now controls attribute truncation, and truncated bytes are recorded in `_truncated` [#66616](https://github.com/pingcap/tidb/issues/66616) @[jiong-nba](https://github.com/jiong-nba) +- Improve the performance and stability of runaway query watch handling, including more reliable watch synchronization across TiDB instances and more efficient background flushing and syncing [#65746](https://github.com/pingcap/tidb/issues/65746) @[JmPotato](https://github.com/JmPotato) +- Add the global system variable `tidb_enable_batch_query_region` to control whether TiDB uses batched Region queries to PD, improving the efficiency of fetching Region information; this variable is disabled by default [#58439](https://github.com/pingcap/tidb/issues/58439) [#8690](https://github.com/tikv/pd/issues/8690) @[JmPotato](https://github.com/JmPotato) +- Improve the optimizer performance for queries on tables with many indexes by pruning irrelevant indexes before cost estimation, reducing query planning time and avoiding unnecessary full-range out-of-range estimation [#63856](https://github.com/pingcap/tidb/issues/63856) @[terry1purcell](https://github.com/terry1purcell) @[qw4990](https://github.com/qw4990) +- Support partial ordered index optimization for `ORDER BY ... LIMIT/OFFSET` queries on matching prefix indexes. When `tidb_opt_partial_ordered_index_for_topn` is set to `COST`, TiDB can use the partial ordering of indexes to reduce full table scans and improve `TOPN` query performance [#63280](https://github.com/pingcap/tidb/issues/63280) [#65813](https://github.com/pingcap/tidb/issues/65813) [#66338](https://github.com/pingcap/tidb/issues/66338) @[elsa0520](https://github.com/elsa0520) @[xzhangxian1008](https://github.com/xzhangxian1008) @[winoros](https://github.com/winoros) +- Mitigate coprocessor request bursts for `IndexLookUp` queries on highly partitioned tables with local indexes to improve query stability and reduce performance spikes [#67545](https://github.com/pingcap/tidb/issues/67545) @[gengliqi](https://github.com/gengliqi) +- Optimize CPU and memory usage for `INSERT ... ON DUPLICATE KEY UPDATE` statements by reducing unnecessary expression buffer allocations during execution [#65003](https://github.com/pingcap/tidb/issues/65003) @[windtalker](https://github.com/windtalker) +- Add the `tidb_opt_enable_alternative_logical_plans` system variable to enable alternative logical plan optimization for subquery decorrelation [#66676](https://github.com/pingcap/tidb/issues/66676) @[AilinKid](https://github.com/AilinKid) +- Optimize the logic for timestamp advancement and leader election [#9981](https://github.com/tikv/pd/issues/9981) @[bufferflies](https://github.com/bufferflies) +- Support batch configuration of TiKV store limits by storage engine (TiKV or TiFlash) [#9970](https://github.com/tikv/pd/issues/9970) @[bufferflies](https://github.com/bufferflies) +- Add the `store` label to the `pd_cluster_status` metric [#9855](https://github.com/tikv/pd/issues/9855) @[SerjKol80](https://github.com/SerjKol80) +- Return `404` instead of `200` when deleting a non-existent label [#10089](https://github.com/tikv/pd/issues/10089) @[lhy1024](https://github.com/lhy1024) \ No newline at end of file From c553e450f0bb5018fb34f5526f6665cba9494614 Mon Sep 17 00:00:00 2001 From: qiancai Date: Thu, 6 Aug 2026 17:58:13 +0800 Subject: [PATCH 02/15] update inline comments --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 52 ++++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index 7a09baea93da0..be615d3b1fec5 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -22,7 +22,7 @@ In `TiDB-X-CLOUD.202603.1`: ### Performance -* Introduce significant performance improvements for certain lossy DDL operations (such as `BIGINT → INT` and `CHAR(120) → VARCHAR(60)`): when no data truncation occurs, the execution time of these operations can be reduced from hours to minutes, seconds, or even milliseconds, delivering performance gains ranging from tens to hundreds of thousands of times [#63366](https://github.com/pingcap/tidb/issues/63366) @[wjhuang2016](https://github.com/wjhuang2016), @[tangenta](https://github.com/tangenta), @[fzzf678](https://github.com/fzzf678) +* Introduce significant performance improvements for certain lossy DDL operations (such as `BIGINT → INT` and `CHAR(120) → VARCHAR(60)`): when no data truncation occurs, the execution time of these operations can be reduced from hours to minutes, seconds, or even milliseconds, delivering performance gains ranging from tens to hundreds of thousands of times [#63366](https://github.com/pingcap/tidb/issues/63366) @[wjhuang2016](https://github.com/wjhuang2016), @[tangenta](https://github.com/tangenta), @[fzzf678](https://github.com/fzzf678) The optimization strategies are as follows: @@ -42,7 +42,7 @@ In `TiDB-X-CLOUD.202603.1`: For more information, see [documentation](/sql-statements/sql-statement-modify-column.md). -* Support pushing index lookups down to TiKV to improve query performance [#62575](https://github.com/pingcap/tidb/issues/62575) @[lcwangchao](https://github.com/lcwangchao) +* Support pushing index lookups down to TiKV to improve query performance [#62575](https://github.com/pingcap/tidb/issues/62575) @[lcwangchao](https://github.com/lcwangchao) Now TiDB supports using [optimizer hints](/optimizer-hints.md) to push the `IndexLookUp` operator down to TiKV nodes. This reduces the number of remote procedure calls (RPCs) and can improve query performance. The actual performance improvement varies depending on the specific workload and requires testing for verification. @@ -52,7 +52,7 @@ In `TiDB-X-CLOUD.202603.1`: For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855). -* Support table-level data affinity to improve query performance (experimental) [#9764](https://github.com/tikv/pd/issues/9764) @[lhy1024](https://github.com/lhy1024) +* Support table-level data affinity to improve query performance (experimental) [#9764](https://github.com/tikv/pd/issues/9764) @[lhy1024](https://github.com/lhy1024) Now you can configure the `AFFINITY` table option as `table` or `partition` when creating or altering a table. When this option is enabled, PD groups Regions that belong to the same table or the same partition into a single affinity group. During scheduling, PD prioritizes placing the Leaders and Voter replicas of these Regions on the same subset of a few TiKV nodes. In this scenario, by using the [`INDEX_LOOKUP_PUSHDOWN`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855) hint in queries, you can explicitly instruct the optimizer to push index lookups down to TiKV, reducing the latency caused by cross-node scattered queries and improving query performance. @@ -60,7 +60,7 @@ In `TiDB-X-CLOUD.202603.1`: For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/table-affinity). -* Foreign key checks now support shared locks [#66154](https://github.com/pingcap/tidb/issues/66154) @[you06](https://github.com/you06) +* Foreign key checks now support shared locks [#66154](https://github.com/pingcap/tidb/issues/66154) @[you06](https://github.com/you06) In pessimistic transactions, when you run `INSERT` or `UPDATE` on a child table with foreign key constraints, foreign key checks lock the corresponding parent table rows with exclusive locks by default. In high-concurrency write scenarios on the child table, if many transactions access the same parent table rows, severe lock contention can occur. @@ -70,7 +70,7 @@ In `TiDB-X-CLOUD.202603.1`: ### Stability -* The feature of setting the maximum limit on resource usage for background tasks of resource control becomes generally available (GA) [#56019](https://github.com/pingcap/tidb/issues/56019) @[glorv](https://github.com/glorv) +* The feature of setting the maximum limit on resource usage for background tasks of resource control becomes generally available (GA) [#56019](https://github.com/pingcap/tidb/issues/56019) @[glorv](https://github.com/glorv) TiDB resource control can identify and lower the priority of background tasks. In certain scenarios, you might want to limit the resource consumption of background tasks, even when resources are available. Starting from v8.4.0, you can use the `UTILIZATION_LIMIT` parameter to set the maximum percentage of resources that background tasks can consume. Each node will keep the resource usage of all background tasks below this percentage. This feature enables precise control over resource consumption for background tasks, further enhancing cluster stability. @@ -80,7 +80,7 @@ In `TiDB-X-CLOUD.202603.1`: ### Observability -* Support defining multi-dimensional, fine-grained trigger rules for slow query logs [#62959](https://github.com/pingcap/tidb/issues/62959), [#64010](https://github.com/pingcap/tidb/issues/64010) @[zimulala](https://github.com/zimulala) +* Support defining multi-dimensional, fine-grained trigger rules for slow query logs [#62959](https://github.com/pingcap/tidb/issues/62959), [#64010](https://github.com/pingcap/tidb/issues/64010) @[zimulala](https://github.com/zimulala) Before v8.5.6, the main way to identify slow queries in TiDB is to set the [`tidb_slow_log_threshold`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_threshold) system variable. This mechanism provides only coarse-grained control over slow query log triggering because it applies globally at the instance level and does not support fine-grained control at the session or SQL level. In addition, it supports only one trigger condition, execution time (`Query_time`), which cannot meet the need to capture slow query logs more precisely in complex scenarios. @@ -90,7 +90,7 @@ In `TiDB-X-CLOUD.202603.1`: ### SQL -* Support using table aliases in the `FOR UPDATE OF` clause [#63035](https://github.com/pingcap/tidb/issues/63035) @[cryo-zd](https://github.com/cryo-zd) +* Support using table aliases in the `FOR UPDATE OF` clause [#63035](https://github.com/pingcap/tidb/issues/63035) @[cryo-zd](https://github.com/cryo-zd) Before this release, when a `SELECT ... FOR UPDATE OF
` statement references a table alias in the locking clause, TiDB might fail to resolve the alias correctly and return the `table not exists` error even if the alias is valid. @@ -98,7 +98,7 @@ In `TiDB-X-CLOUD.202603.1`: For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/sql-statement-select). -* Support partial indexes to reduce index storage and DML maintenance overhead [#62664](https://github.com/pingcap/tidb/issues/62664) [#62761](https://github.com/pingcap/tidb/issues/62761) [#62758](https://github.com/pingcap/tidb/issues/62758) [#63447](https://github.com/pingcap/tidb/issues/63447) [#64344](https://github.com/pingcap/tidb/issues/64344) @[YangKeao](https://github.com/YangKeao) @[winoros](https://github.com/winoros) @[wjhuang2016](https://github.com/wjhuang2016) +* Support partial indexes to reduce index storage and DML maintenance overhead [#62664](https://github.com/pingcap/tidb/issues/62664) [#62761](https://github.com/pingcap/tidb/issues/62761) [#62758](https://github.com/pingcap/tidb/issues/62758) [#63447](https://github.com/pingcap/tidb/issues/63447) [#64344](https://github.com/pingcap/tidb/issues/64344) @[YangKeao](https://github.com/YangKeao) @[winoros](https://github.com/winoros) @[wjhuang2016](https://github.com/wjhuang2016) Now TiDB supports partial indexes, which index only rows that satisfy a predicate defined in the index `WHERE` clause. You can create a partial index using `CREATE INDEX ... WHERE ...`, `ALTER TABLE ... ADD INDEX ... WHERE ...`, or an index definition in `CREATE TABLE`. @@ -112,27 +112,27 @@ In `TiDB-X-CLOUD.202603.1`: ### MySQL compatibility -* Dumpling supports exporting data from MySQL 8.4 by adapting to the updated MySQL binary log naming. [#53082](https://github.com/pingcap/tidb/issues/53082) @[dveeden](https://github.com/dveeden) +* Dumpling supports exporting data from MySQL 8.4 by adapting to the updated MySQL binary log naming. [#53082](https://github.com/pingcap/tidb/issues/53082) @[dveeden](https://github.com/dveeden) -* Support parsing the `LATERAL` syntax for derived tables to improve MySQL 8.0 compatibility, including comma joins, `CROSS JOIN LATERAL`, and `INNER JOIN LATERAL` +* Support parsing the `LATERAL` syntax for derived tables to improve MySQL 8.0 compatibility, including comma joins, `CROSS JOIN LATERAL`, and `INNER JOIN LATERAL` Currently, TiDB only supports parsing [the `LATERAL` derived table syntax](https://docs.pingcap.com/tidb/v8.5/lateral-derived-tables) and does not support executing queries that use this syntax. If you attempt to execute such a query, TiDB returns an error. You can track the progress of full execution capability for this feature in issue [#40328](https://github.com/pingcap/tidb/issues/40328). ## Improvements -- Enhance the parsing mechanism for Parquet files to improve the import performance of Parquet-formatted data [#62906](https://github.com/pingcap/tidb/issues/62906) @[joechenrh](https://github.com/joechenrh) -- Change the default value of `tidb_analyze_column_options` to `ALL` to collect statistics for all columns by default [#64992](https://github.com/pingcap/tidb/issues/64992) @[0xPoe](https://github.com/0xPoe) -- Optimize the execution logic of the `IndexHashJoin` operator by using incremental processing in specific JOIN scenarios to avoid loading large amounts of data at once, significantly reducing memory usage and improving performance [#63303](https://github.com/pingcap/tidb/issues/63303) @[ChangRui-Ryan](https://github.com/ChangRui-Ryan) -- Improve slow query log readability by outputting non-printable prepared statement arguments as hexadecimal values [#65383](https://github.com/pingcap/tidb/issues/65383) @[dveeden](https://github.com/dveeden) -- Improve slow query observability by logging client connection attributes in the slow query log and making them queryable in `INFORMATION_SCHEMA.SLOW_QUERY` and `INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY`; `performance_schema_session_connect_attrs_size` now controls attribute truncation, and truncated bytes are recorded in `_truncated` [#66616](https://github.com/pingcap/tidb/issues/66616) @[jiong-nba](https://github.com/jiong-nba) -- Improve the performance and stability of runaway query watch handling, including more reliable watch synchronization across TiDB instances and more efficient background flushing and syncing [#65746](https://github.com/pingcap/tidb/issues/65746) @[JmPotato](https://github.com/JmPotato) -- Add the global system variable `tidb_enable_batch_query_region` to control whether TiDB uses batched Region queries to PD, improving the efficiency of fetching Region information; this variable is disabled by default [#58439](https://github.com/pingcap/tidb/issues/58439) [#8690](https://github.com/tikv/pd/issues/8690) @[JmPotato](https://github.com/JmPotato) -- Improve the optimizer performance for queries on tables with many indexes by pruning irrelevant indexes before cost estimation, reducing query planning time and avoiding unnecessary full-range out-of-range estimation [#63856](https://github.com/pingcap/tidb/issues/63856) @[terry1purcell](https://github.com/terry1purcell) @[qw4990](https://github.com/qw4990) -- Support partial ordered index optimization for `ORDER BY ... LIMIT/OFFSET` queries on matching prefix indexes. When `tidb_opt_partial_ordered_index_for_topn` is set to `COST`, TiDB can use the partial ordering of indexes to reduce full table scans and improve `TOPN` query performance [#63280](https://github.com/pingcap/tidb/issues/63280) [#65813](https://github.com/pingcap/tidb/issues/65813) [#66338](https://github.com/pingcap/tidb/issues/66338) @[elsa0520](https://github.com/elsa0520) @[xzhangxian1008](https://github.com/xzhangxian1008) @[winoros](https://github.com/winoros) -- Mitigate coprocessor request bursts for `IndexLookUp` queries on highly partitioned tables with local indexes to improve query stability and reduce performance spikes [#67545](https://github.com/pingcap/tidb/issues/67545) @[gengliqi](https://github.com/gengliqi) -- Optimize CPU and memory usage for `INSERT ... ON DUPLICATE KEY UPDATE` statements by reducing unnecessary expression buffer allocations during execution [#65003](https://github.com/pingcap/tidb/issues/65003) @[windtalker](https://github.com/windtalker) -- Add the `tidb_opt_enable_alternative_logical_plans` system variable to enable alternative logical plan optimization for subquery decorrelation [#66676](https://github.com/pingcap/tidb/issues/66676) @[AilinKid](https://github.com/AilinKid) -- Optimize the logic for timestamp advancement and leader election [#9981](https://github.com/tikv/pd/issues/9981) @[bufferflies](https://github.com/bufferflies) -- Support batch configuration of TiKV store limits by storage engine (TiKV or TiFlash) [#9970](https://github.com/tikv/pd/issues/9970) @[bufferflies](https://github.com/bufferflies) -- Add the `store` label to the `pd_cluster_status` metric [#9855](https://github.com/tikv/pd/issues/9855) @[SerjKol80](https://github.com/SerjKol80) -- Return `404` instead of `200` when deleting a non-existent label [#10089](https://github.com/tikv/pd/issues/10089) @[lhy1024](https://github.com/lhy1024) \ No newline at end of file +- Enhance the parsing mechanism for Parquet files to improve the import performance of Parquet-formatted data [#62906](https://github.com/pingcap/tidb/issues/62906) @[joechenrh](https://github.com/joechenrh) +- Change the default value of `tidb_analyze_column_options` to `ALL` to collect statistics for all columns by default [#64992](https://github.com/pingcap/tidb/issues/64992) @[0xPoe](https://github.com/0xPoe) +- Optimize the execution logic of the `IndexHashJoin` operator by using incremental processing in specific JOIN scenarios to avoid loading large amounts of data at once, significantly reducing memory usage and improving performance [#63303](https://github.com/pingcap/tidb/issues/63303) @[ChangRui-Ryan](https://github.com/ChangRui-Ryan) +- Improve slow query log readability by outputting non-printable prepared statement arguments as hexadecimal values [#65383](https://github.com/pingcap/tidb/issues/65383) @[dveeden](https://github.com/dveeden) +- Improve slow query observability by logging client connection attributes in the slow query log and making them queryable in `INFORMATION_SCHEMA.SLOW_QUERY` and `INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY`; `performance_schema_session_connect_attrs_size` now controls attribute truncation, and truncated bytes are recorded in `_truncated` [#66616](https://github.com/pingcap/tidb/issues/66616) @[jiong-nba](https://github.com/jiong-nba) +- Improve the performance and stability of runaway query watch handling, including more reliable watch synchronization across TiDB instances and more efficient background flushing and syncing [#65746](https://github.com/pingcap/tidb/issues/65746) @[JmPotato](https://github.com/JmPotato) +- Add the global system variable `tidb_enable_batch_query_region` to control whether TiDB uses batched Region queries to PD, improving the efficiency of fetching Region information; this variable is disabled by default [#58439](https://github.com/pingcap/tidb/issues/58439) [#8690](https://github.com/tikv/pd/issues/8690) @[JmPotato](https://github.com/JmPotato) +- Improve the optimizer performance for queries on tables with many indexes by pruning irrelevant indexes before cost estimation, reducing query planning time and avoiding unnecessary full-range out-of-range estimation [#63856](https://github.com/pingcap/tidb/issues/63856) @[terry1purcell](https://github.com/terry1purcell) @[qw4990](https://github.com/qw4990) +- Support partial ordered index optimization for `ORDER BY ... LIMIT/OFFSET` queries on matching prefix indexes. When `tidb_opt_partial_ordered_index_for_topn` is set to `COST`, TiDB can use the partial ordering of indexes to reduce full table scans and improve `TOPN` query performance [#63280](https://github.com/pingcap/tidb/issues/63280) [#65813](https://github.com/pingcap/tidb/issues/65813) [#66338](https://github.com/pingcap/tidb/issues/66338) @[elsa0520](https://github.com/elsa0520) @[xzhangxian1008](https://github.com/xzhangxian1008) @[winoros](https://github.com/winoros) +- Mitigate coprocessor request bursts for `IndexLookUp` queries on highly partitioned tables with local indexes to improve query stability and reduce performance spikes [#67545](https://github.com/pingcap/tidb/issues/67545) @[gengliqi](https://github.com/gengliqi) +- Optimize CPU and memory usage for `INSERT ... ON DUPLICATE KEY UPDATE` statements by reducing unnecessary expression buffer allocations during execution [#65003](https://github.com/pingcap/tidb/issues/65003) @[windtalker](https://github.com/windtalker) +- Add the `tidb_opt_enable_alternative_logical_plans` system variable to enable alternative logical plan optimization for subquery decorrelation [#66676](https://github.com/pingcap/tidb/issues/66676) @[AilinKid](https://github.com/AilinKid) +- Optimize the logic for timestamp advancement and leader election [#9981](https://github.com/tikv/pd/issues/9981) @[bufferflies](https://github.com/bufferflies) +- Support batch configuration of TiKV store limits by storage engine (TiKV or TiFlash) [#9970](https://github.com/tikv/pd/issues/9970) @[bufferflies](https://github.com/bufferflies) +- Add the `store` label to the `pd_cluster_status` metric [#9855](https://github.com/tikv/pd/issues/9855) @[SerjKol80](https://github.com/SerjKol80) +- Return `404` instead of `200` when deleting a non-existent label [#10089](https://github.com/tikv/pd/issues/10089) @[lhy1024](https://github.com/lhy1024) From d515597369d4cc7de1323fc9036e60227b5385df Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 6 Aug 2026 18:08:40 +0800 Subject: [PATCH 03/15] Apply suggestions from code review --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index be615d3b1fec5..15df8443a4fc9 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -5,13 +5,13 @@ summary: Learn about the features for the TiDB-X-CLOUD.202603.1 kernel. # TiDB-X-CLOUD.202603.1 Release Notes -**Release date**: April 28, 2026 +**Release date**: July 16, 2026 **Applicable TiDB Cloud plan**: {{{ .premium }}} **TiDB X kernel version**: `TiDB-X-CLOUD.202603.1` -{{{ .premium }}} is available in public preview starting April 28, 2026, using the `TiDB-X-CLOUD.202603.1` kernel. +Starting from July 16, 2026, the default kernel version of newly created {{{ .premium }}} instances is `TiDB-X-CLOUD.202603.1`. In `TiDB-X-CLOUD.202603.1`: From 15f47e517b17f73db73bc7f90211408b2adbe58f Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 8 Sep 2026 10:39:49 +0800 Subject: [PATCH 04/15] removed info about shared locks --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index 15df8443a4fc9..27c240e3d0ead 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -60,13 +60,6 @@ In `TiDB-X-CLOUD.202603.1`: For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/table-affinity). -* Foreign key checks now support shared locks [#66154](https://github.com/pingcap/tidb/issues/66154) @[you06](https://github.com/you06) - - In pessimistic transactions, when you run `INSERT` or `UPDATE` on a child table with foreign key constraints, foreign key checks lock the corresponding parent table rows with exclusive locks by default. In high-concurrency write scenarios on the child table, if many transactions access the same parent table rows, severe lock contention can occur. - - Now you can set the [`tidb_foreign_key_check_in_shared_lock`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_foreign_key_check_in_shared_lock-new-in-v856) system variable to `ON` to let foreign key checks use shared locks on the parent table, thereby reducing lock contention and improving concurrent write performance on the child table. - - For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/foreign-key#locking). ### Stability From ee2ca700929077c1b170aa8262b1f790655ea96a Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 8 Sep 2026 15:27:50 +0800 Subject: [PATCH 05/15] remove info about table-level data affinity --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 9 --------- 1 file changed, 9 deletions(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index 27c240e3d0ead..4ff68a7ed1d83 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -52,15 +52,6 @@ In `TiDB-X-CLOUD.202603.1`: For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855). -* Support table-level data affinity to improve query performance (experimental) [#9764](https://github.com/tikv/pd/issues/9764) @[lhy1024](https://github.com/lhy1024) - - Now you can configure the `AFFINITY` table option as `table` or `partition` when creating or altering a table. When this option is enabled, PD groups Regions that belong to the same table or the same partition into a single affinity group. During scheduling, PD prioritizes placing the Leaders and Voter replicas of these Regions on the same subset of a few TiKV nodes. In this scenario, by using the [`INDEX_LOOKUP_PUSHDOWN`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855) hint in queries, you can explicitly instruct the optimizer to push index lookups down to TiKV, reducing the latency caused by cross-node scattered queries and improving query performance. - - Note that this feature is currently experimental and is disabled by default. To enable it, set the PD configuration item [`schedule.affinity-schedule-limit`](https://docs.pingcap.com/tidb/v8.5/pd-configuration-file#affinity-schedule-limit-new-in-v855) to a value greater than `0`. This configuration item controls the maximum number of affinity scheduling tasks that PD can perform concurrently. - - For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/table-affinity). - - ### Stability * The feature of setting the maximum limit on resource usage for background tasks of resource control becomes generally available (GA) [#56019](https://github.com/pingcap/tidb/issues/56019) @[glorv](https://github.com/glorv) From bccdf8d620aea4027975e764f12c3474c5966e2d Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 8 Sep 2026 15:31:22 +0800 Subject: [PATCH 06/15] remove setting the maximum limit on resource usage for background tasks of resource control --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index 4ff68a7ed1d83..a4c75d542d610 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -52,16 +52,6 @@ In `TiDB-X-CLOUD.202603.1`: For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855). -### Stability - -* The feature of setting the maximum limit on resource usage for background tasks of resource control becomes generally available (GA) [#56019](https://github.com/pingcap/tidb/issues/56019) @[glorv](https://github.com/glorv) - - TiDB resource control can identify and lower the priority of background tasks. In certain scenarios, you might want to limit the resource consumption of background tasks, even when resources are available. Starting from v8.4.0, you can use the `UTILIZATION_LIMIT` parameter to set the maximum percentage of resources that background tasks can consume. Each node will keep the resource usage of all background tasks below this percentage. This feature enables precise control over resource consumption for background tasks, further enhancing cluster stability. - - Now this feature is generally available (GA). - - For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/tidb-resource-control-background-tasks). - ### Observability * Support defining multi-dimensional, fine-grained trigger rules for slow query logs [#62959](https://github.com/pingcap/tidb/issues/62959), [#64010](https://github.com/pingcap/tidb/issues/64010) @[zimulala](https://github.com/zimulala) From 687449ce59e9c5dc33e010e61d8701be9ab12524 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 8 Sep 2026 15:42:28 +0800 Subject: [PATCH 07/15] remove the info about pushing index lookups down to TiKV --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index a4c75d542d610..1838d9e4c136a 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -42,16 +42,6 @@ In `TiDB-X-CLOUD.202603.1`: For more information, see [documentation](/sql-statements/sql-statement-modify-column.md). -* Support pushing index lookups down to TiKV to improve query performance [#62575](https://github.com/pingcap/tidb/issues/62575) @[lcwangchao](https://github.com/lcwangchao) - - Now TiDB supports using [optimizer hints](/optimizer-hints.md) to push the `IndexLookUp` operator down to TiKV nodes. This reduces the number of remote procedure calls (RPCs) and can improve query performance. The actual performance improvement varies depending on the specific workload and requires testing for verification. - - To explicitly instruct the optimizer to push index lookups down to TiKV for a specific table, you can use the [`INDEX_LOOKUP_PUSHDOWN(t1_name, idx1_name [, idx2_name ...])`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855) hint. It is recommended to combine this hint with the table's AFFINITY attribute. For example, set `AFFINITY="table"` for regular tables and `AFFINITY="partition"` for partitioned tables. - - To disable index lookup pushdown to TiKV for a specific table, use the [`NO_INDEX_LOOKUP_PUSHDOWN(t1_name)`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#no_index_lookup_pushdownt1_name-new-in-v855) hint. - - For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855). - ### Observability * Support defining multi-dimensional, fine-grained trigger rules for slow query logs [#62959](https://github.com/pingcap/tidb/issues/62959), [#64010](https://github.com/pingcap/tidb/issues/64010) @[zimulala](https://github.com/zimulala) From f5e39c07eb3c989ba5dbd5a0f0719d7643c34d11 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 8 Sep 2026 15:48:47 +0800 Subject: [PATCH 08/15] Apply suggestions from code review --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index 1838d9e4c136a..333e7d3a929da 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -40,7 +40,7 @@ In `TiDB-X-CLOUD.202603.1`: Note that the preceding test results are based on the condition that no data truncation occurs during the DDL execution. The optimizations do not apply to conversions between signed and unsigned integer types, conversions between character sets, or tables with TiFlash replicas. - For more information, see [documentation](/sql-statements/sql-statement-modify-column.md). + For more information, see [documentation](https://docs.pingcap.com/tidbcloud/sql-statement-modify-column/?plan=premium). ### Observability @@ -50,7 +50,7 @@ In `TiDB-X-CLOUD.202603.1`: Starting from v8.5.6, TiDB enhances slow query log control. You can use the [`tidb_slow_log_rules`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_rules-new-in-v856) system variable to define multi-dimensional slow query log output rules at the instance, session, and SQL levels, based on conditions such as `Query_time`, `Digest`, `Mem_max`, and `KV_total`. You can use [`tidb_slow_log_max_per_sec`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_max_per_sec-new-in-v856) to limit the number of log entries written per second, and use the [`WRITE_SLOW_LOG`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints) hint to force slow query logging for specific SQL statements. This enables more flexible and fine-grained control over slow query logs. - For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/identify-slow-queries). + For more information, see [documentation](https://docs.pingcap.com/tidbcloud/config-slow-query-trigger-rules/?plan=premium). ### SQL @@ -60,7 +60,7 @@ In `TiDB-X-CLOUD.202603.1`: Now TiDB supports using table aliases in the `FOR UPDATE OF` clause. TiDB can now correctly resolve locking targets from the `FROM` clause, including aliased tables, ensuring that row locks take effect as expected. This improves MySQL compatibility and makes `SELECT ... FOR UPDATE OF` statements more stable and reliable in queries that use table aliases. - For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/sql-statement-select). + For more information, see [documentation](https://docs.pingcap.com/tidbcloud/sql-statement-modify-column/?plan=premium). * Support partial indexes to reduce index storage and DML maintenance overhead [#62664](https://github.com/pingcap/tidb/issues/62664) [#62761](https://github.com/pingcap/tidb/issues/62761) [#62758](https://github.com/pingcap/tidb/issues/62758) [#63447](https://github.com/pingcap/tidb/issues/63447) [#64344](https://github.com/pingcap/tidb/issues/64344) @[YangKeao](https://github.com/YangKeao) @[winoros](https://github.com/winoros) @[wjhuang2016](https://github.com/wjhuang2016) @@ -70,7 +70,7 @@ In `TiDB-X-CLOUD.202603.1`: To use partial indexes effectively, define a predicate that matches the filters in your common queries. TiDB selects a partial index only when the query predicates match or imply the partial index predicate. Currently, partial index predicates support basic comparison operators (`=`, `!=`, `<`, `<=`, `>`, `>=`), `IS NULL`, `IS NOT NULL`, and `IN` predicates with constant values. - For more information, see [documentation](https://docs.pingcap.com/tidb/v8.5/sql-statement-create-index#partial-indexes). + For more information, see [documentation](https://docs.pingcap.com/tidbcloud/sql-statement-create-index/?plan=premium#partial-indexes-new-in-v857). ## Compatibility changes From c477f3e297f53ae1733bb3ef577f123196ee443f Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 8 Sep 2026 18:26:12 +0800 Subject: [PATCH 09/15] Update tidb-cloud/releases/tidb-x-cloud.202603.1.md --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index 333e7d3a929da..5322708db4f67 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -46,9 +46,9 @@ In `TiDB-X-CLOUD.202603.1`: * Support defining multi-dimensional, fine-grained trigger rules for slow query logs [#62959](https://github.com/pingcap/tidb/issues/62959), [#64010](https://github.com/pingcap/tidb/issues/64010) @[zimulala](https://github.com/zimulala) - Before v8.5.6, the main way to identify slow queries in TiDB is to set the [`tidb_slow_log_threshold`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_threshold) system variable. This mechanism provides only coarse-grained control over slow query log triggering because it applies globally at the instance level and does not support fine-grained control at the session or SQL level. In addition, it supports only one trigger condition, execution time (`Query_time`), which cannot meet the need to capture slow query logs more precisely in complex scenarios. + In TiDB Cloud, SQL queries that take more than 300 milliseconds are considered slow queries by default. You can view slow queries on the [**Slow Query**](/tidb-cloud/tune-performance.md#slow-query) tab of the [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) page in the [TiDB Cloud console](/tidb-cloud/index.md). - Starting from v8.5.6, TiDB enhances slow query log control. You can use the [`tidb_slow_log_rules`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_rules-new-in-v856) system variable to define multi-dimensional slow query log output rules at the instance, session, and SQL levels, based on conditions such as `Query_time`, `Digest`, `Mem_max`, and `KV_total`. You can use [`tidb_slow_log_max_per_sec`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_max_per_sec-new-in-v856) to limit the number of log entries written per second, and use the [`WRITE_SLOW_LOG`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints) hint to force slow query logging for specific SQL statements. This enables more flexible and fine-grained control over slow query logs. + TiDB Cloud now provides more flexible control over slow query logging. You can use the [`tidb_slow_log_rules`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_rules-new-in-v856) system variable to define multi-dimensional slow query log output rules at the instance, session, and SQL levels, based on conditions such as `Query_time`, `Digest`, `Mem_max`, and `KV_total`. You can use the [`WRITE_SLOW_LOG`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints) hint to force slow query logging for specific SQL statements. This enables more flexible and fine-grained control over slow query logs. For more information, see [documentation](https://docs.pingcap.com/tidbcloud/config-slow-query-trigger-rules/?plan=premium). From f06d4e37bebec0bfeae15ac31217d10947fbd637 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 8 Sep 2026 18:26:22 +0800 Subject: [PATCH 10/15] Update tidb-cloud/releases/tidb-x-cloud.202603.1.md --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index 5322708db4f67..876c4967e015c 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -44,7 +44,7 @@ In `TiDB-X-CLOUD.202603.1`: ### Observability -* Support defining multi-dimensional, fine-grained trigger rules for slow query logs [#62959](https://github.com/pingcap/tidb/issues/62959), [#64010](https://github.com/pingcap/tidb/issues/64010) @[zimulala](https://github.com/zimulala) +* Support defining multi-dimensional, fine-grained trigger rules for slow queries [#62959](https://github.com/pingcap/tidb/issues/62959), [#64010](https://github.com/pingcap/tidb/issues/64010) @[zimulala](https://github.com/zimulala) In TiDB Cloud, SQL queries that take more than 300 milliseconds are considered slow queries by default. You can view slow queries on the [**Slow Query**](/tidb-cloud/tune-performance.md#slow-query) tab of the [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) page in the [TiDB Cloud console](/tidb-cloud/index.md). From 813c077f81415922a96f9ca16af89268487bec95 Mon Sep 17 00:00:00 2001 From: qiancai Date: Tue, 8 Sep 2026 18:54:31 +0800 Subject: [PATCH 11/15] add the tidb x version info --- sql-statements/sql-statement-create-index.md | 4 +++- sql-statements/sql-statement-modify-column.md | 1 + sql-statements/sql-statement-select.md | 2 +- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index cabcd5115dbf2..ea1a677afceee 100644 --- a/sql-statements/sql-statement-create-index.md +++ b/sql-statements/sql-statement-create-index.md @@ -366,7 +366,9 @@ See [Index Selection - Use multi-valued indexes](/choose-index.md#use-multi-valu - If a table uses multi-valued indexes, you cannot back up, replicate, or import the table using BR, TiCDC, or TiDB Lightning to a TiDB cluster earlier than v6.6.0. - For a query with complex conditions, TiDB might not be able to select multi-valued indexes. For information on the condition patterns supported by multi-valued indexes, refer to [Use multi-valued indexes](/choose-index.md#use-multi-valued-indexes). -## Partial indexes New in v8.5.7 +## Partial indexes + +New in v8.5.7 for TiDB Self-Managed and TiDB Cloud Dedicated, and CLOUD.202603.1 for TiDB Cloud Essential and Premium A partial index is an index built on a subset of rows in a table. When creating a partial index, you can specify a conditional expression, also known as a predicate, to define that subset of rows. The index contains entries only for the rows that satisfy the predicate. diff --git a/sql-statements/sql-statement-modify-column.md b/sql-statements/sql-statement-modify-column.md index fd387ab59820b..8da20f46b1c10 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -16,6 +16,7 @@ The following are some common examples of column type changes that require Reorg - Reducing the length of `VARCHAR(10)` to `VARCHAR(5)` Starting from v8.5.5, TiDB optimizes some column type changes that previously required Reorg-Data. When the following conditions are met, TiDB rebuilds only the affected indexes instead of the entire table, thereby improving execution efficiency: +In v8.5.5 and later versions for TiDB Self-Managed and TiDB Cloud Dedicated, and CLOUD.202603.1 and later versions for TiDB Cloud Essential and Premium, TiDB optimizes some column type changes that previously required Reorg-Data. When the following conditions are met, TiDB rebuilds only the affected indexes instead of the entire table, thereby improving execution efficiency: - The current session uses a strict [SQL mode](/sql-mode.md) (`sql_mode` includes `STRICT_TRANS_TABLES` or `STRICT_ALL_TABLES`). - The table has no TiFlash replicas. diff --git a/sql-statements/sql-statement-select.md b/sql-statements/sql-statement-select.md index d683c76dfd155..437015c1d96eb 100644 --- a/sql-statements/sql-statement-select.md +++ b/sql-statements/sql-statement-select.md @@ -106,7 +106,7 @@ TableSample ::= > **Note:** > -> - Starting from v8.5.6, TiDB supports using table aliases in the `FOR UPDATE OF` clause. To maintain backward compatibility, you can still reference the base table name when an alias is defined, but this triggers a warning that recommends using the explicit alias. When a query involves multiple tables with the same name across different databases (for example, `FROM db1.t, db2.t FOR UPDATE OF t`), TiDB now matches the target table from left to right based on the order in the `FROM` clause, rather than the current database context. To avoid ambiguity, it is recommended that you specify the database name or use aliases in the `FOR UPDATE OF` clause. +> - In v8.5.6 and later version for TiDB Self-Managed and TiDB Cloud Dedicated, and CLOUD.202603.1 and later version for TiDB Cloud Essential and Premium, TiDB supports using table aliases in the `FOR UPDATE OF` clause. To maintain backward compatibility, you can still reference the base table name when an alias is defined, but this triggers a warning that recommends using the explicit alias. When a query involves multiple tables with the same name across different databases (for example, `FROM db1.t, db2.t FOR UPDATE OF t`), TiDB now matches the target table from left to right based on the order in the `FROM` clause, rather than the current database context. To avoid ambiguity, it is recommended that you specify the database name or use aliases in the `FOR UPDATE OF` clause. > - Starting from v6.6.0, TiDB supports [Resource Control](/tidb-resource-control-ru-groups.md). You can use this feature to execute SQL statements with different priorities in different resource groups. By configuring proper quotas and priorities for these resource groups, you can gain better scheduling control for SQL statements with different priorities. When resource control is enabled, statement priority (`HIGH_PRIORITY`) will no longer take effect. It is recommended that you use [Resource Control](/tidb-resource-control-ru-groups.md) to manage resource usage for different SQL statements. ## Examples From 8e6d6d57699b48bd11f49275698ff6c337eb3689 Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Tue, 8 Sep 2026 18:55:32 +0800 Subject: [PATCH 12/15] Update tidb-cloud/releases/tidb-x-cloud.202603.1.md --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index 876c4967e015c..b6423bef69135 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -60,7 +60,7 @@ In `TiDB-X-CLOUD.202603.1`: Now TiDB supports using table aliases in the `FOR UPDATE OF` clause. TiDB can now correctly resolve locking targets from the `FROM` clause, including aliased tables, ensuring that row locks take effect as expected. This improves MySQL compatibility and makes `SELECT ... FOR UPDATE OF` statements more stable and reliable in queries that use table aliases. - For more information, see [documentation](https://docs.pingcap.com/tidbcloud/sql-statement-modify-column/?plan=premium). + For more information, see [documentation](https://docs.pingcap.com/tidbcloud/sql-statement-select/?plan=premium). * Support partial indexes to reduce index storage and DML maintenance overhead [#62664](https://github.com/pingcap/tidb/issues/62664) [#62761](https://github.com/pingcap/tidb/issues/62761) [#62758](https://github.com/pingcap/tidb/issues/62758) [#63447](https://github.com/pingcap/tidb/issues/63447) [#64344](https://github.com/pingcap/tidb/issues/64344) @[YangKeao](https://github.com/YangKeao) @[winoros](https://github.com/winoros) @[wjhuang2016](https://github.com/wjhuang2016) From 28f3c894492c8c0287f25c577db67e1679269069 Mon Sep 17 00:00:00 2001 From: qiancai Date: Wed, 9 Sep 2026 09:57:28 +0800 Subject: [PATCH 13/15] update the introduce version --- sql-statements/sql-statement-create-index.md | 2 +- sql-statements/sql-statement-modify-column.md | 3 +-- sql-statements/sql-statement-select.md | 2 +- 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index ea1a677afceee..473dbd0dbb52d 100644 --- a/sql-statements/sql-statement-create-index.md +++ b/sql-statements/sql-statement-create-index.md @@ -368,7 +368,7 @@ See [Index Selection - Use multi-valued indexes](/choose-index.md#use-multi-valu ## Partial indexes -New in v8.5.7 for TiDB Self-Managed and TiDB Cloud Dedicated, and CLOUD.202603.1 for TiDB Cloud Essential and Premium +New in v8.5.7 for TiDB Self-Managed and TiDB Cloud Dedicated, and in CLOUD.202603.1 for TiDB Cloud Essential and Premium A partial index is an index built on a subset of rows in a table. When creating a partial index, you can specify a conditional expression, also known as a predicate, to define that subset of rows. The index contains entries only for the rows that satisfy the predicate. diff --git a/sql-statements/sql-statement-modify-column.md b/sql-statements/sql-statement-modify-column.md index 8da20f46b1c10..b88ed8f7688df 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -15,8 +15,7 @@ The following are some common examples of column type changes that require Reorg - Modifying the `DECIMAL` precision - Reducing the length of `VARCHAR(10)` to `VARCHAR(5)` -Starting from v8.5.5, TiDB optimizes some column type changes that previously required Reorg-Data. When the following conditions are met, TiDB rebuilds only the affected indexes instead of the entire table, thereby improving execution efficiency: -In v8.5.5 and later versions for TiDB Self-Managed and TiDB Cloud Dedicated, and CLOUD.202603.1 and later versions for TiDB Cloud Essential and Premium, TiDB optimizes some column type changes that previously required Reorg-Data. When the following conditions are met, TiDB rebuilds only the affected indexes instead of the entire table, thereby improving execution efficiency: +Starting from v8.5.5 for TiDB Self-Managed and TiDB Cloud Dedicated, and from CLOUD.202603.1 for TiDB Cloud Essential and Premium, TiDB optimizes some column type changes that previously required Reorg-Data. When the following conditions are met, TiDB rebuilds only the affected indexes instead of the entire table, thereby improving execution efficiency: - The current session uses a strict [SQL mode](/sql-mode.md) (`sql_mode` includes `STRICT_TRANS_TABLES` or `STRICT_ALL_TABLES`). - The table has no TiFlash replicas. diff --git a/sql-statements/sql-statement-select.md b/sql-statements/sql-statement-select.md index 437015c1d96eb..bb47f82f9e6d0 100644 --- a/sql-statements/sql-statement-select.md +++ b/sql-statements/sql-statement-select.md @@ -106,7 +106,7 @@ TableSample ::= > **Note:** > -> - In v8.5.6 and later version for TiDB Self-Managed and TiDB Cloud Dedicated, and CLOUD.202603.1 and later version for TiDB Cloud Essential and Premium, TiDB supports using table aliases in the `FOR UPDATE OF` clause. To maintain backward compatibility, you can still reference the base table name when an alias is defined, but this triggers a warning that recommends using the explicit alias. When a query involves multiple tables with the same name across different databases (for example, `FROM db1.t, db2.t FOR UPDATE OF t`), TiDB now matches the target table from left to right based on the order in the `FROM` clause, rather than the current database context. To avoid ambiguity, it is recommended that you specify the database name or use aliases in the `FOR UPDATE OF` clause. +> - Starting from v8.5.6 for TiDB Self-Managed and TiDB Cloud Dedicated, and from CLOUD.202603.1 for TiDB Cloud Essential and Premium, TiDB supports using table aliases in the `FOR UPDATE OF` clause. To maintain backward compatibility, you can still reference the base table name when an alias is defined, but this triggers a warning that recommends using the explicit alias. When a query involves multiple tables with the same name across different databases (for example, `FROM db1.t, db2.t FOR UPDATE OF t`), TiDB now matches the target table from left to right based on the order in the `FROM` clause, rather than the current database context. To avoid ambiguity, it is recommended that you specify the database name or use aliases in the `FOR UPDATE OF` clause. > - Starting from v6.6.0, TiDB supports [Resource Control](/tidb-resource-control-ru-groups.md). You can use this feature to execute SQL statements with different priorities in different resource groups. By configuring proper quotas and priorities for these resource groups, you can gain better scheduling control for SQL statements with different priorities. When resource control is enabled, statement priority (`HIGH_PRIORITY`) will no longer take effect. It is recommended that you use [Resource Control](/tidb-resource-control-ru-groups.md) to manage resource usage for different SQL statements. ## Examples From 7523f24a2f3046397c56d0756da02080b3f4990d Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Wed, 9 Sep 2026 10:00:54 +0800 Subject: [PATCH 14/15] Update tidb-cloud/releases/tidb-x-cloud.202603.1.md --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index b6423bef69135..9366eca7449e0 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -7,7 +7,7 @@ summary: Learn about the features for the TiDB-X-CLOUD.202603.1 kernel. **Release date**: July 16, 2026 -**Applicable TiDB Cloud plan**: {{{ .premium }}} +**Applicable TiDB Cloud plan**: {{{ .essential }}} and {{{ .premium }}} **TiDB X kernel version**: `TiDB-X-CLOUD.202603.1` From 2b3ca1c870af1966ad536ab973dea5a5758d419d Mon Sep 17 00:00:00 2001 From: qiancai Date: Thu, 10 Sep 2026 23:50:57 +0800 Subject: [PATCH 15/15] Update tidb-x-cloud.202603.1.md --- tidb-cloud/releases/tidb-x-cloud.202603.1.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md index 9366eca7449e0..e945e8a243b72 100644 --- a/tidb-cloud/releases/tidb-x-cloud.202603.1.md +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -74,6 +74,16 @@ In `TiDB-X-CLOUD.202603.1`: ## Compatibility changes +### System variables + +| Variable name | Change type | Description | +|--------|------------------------------|------| +| [`tidb_paging_size_bytes`](https://docs.pingcap.com/tidbcloud/system-variables#tidb_paging_size_bytes) | Newly added | Controls the maximum size, in bytes, of a single paged response in the coprocessor protocol. The default value is `0`, which disables byte-based pagination. This variable is for internal TiDB use, and it is not recommended to modify its value. | +| [`tidb_slow_log_max_per_sec`](https://docs.pingcap.com/tidbcloud/system-variables#tidb_slow_log_max_per_sec) | Newly added | Controls the maximum number of slow query log entries that can be written per TiDB node per second.
  • A value of `0` (the default) means there is no limit on the number of slow query log entries written per second.
  • A value greater than `0` means TiDB writes at most the specified number of slow query log entries per second. Any excess log entries are discarded and not written to the slow query log file.
This variable is read-only for TiDB Cloud. | +| [`tidb_slow_log_rules`](https://docs.pingcap.com/tidbcloud/system-variables#tidb_slow_log_rules) | Newly added | Defines the triggering rules for slow queries. | +| [`tidb_stmt_summary_group_by_user`](https://docs.pingcap.com/tidbcloud/system-variables#tidb_stmt_summary_group_by_user) | Newly added | Controls whether to include the user who executes SQL statements as an aggregation dimension in statement summary tables. The default value is `ON` for TiDB Cloud Essential and Premium, and this variable is read-only. | +| [`tidb_stmt_summary_persist_evicted`](https://docs.pingcap.com/tidbcloud/system-variables#tidb_stmt_summary_persist_evicted) | Newly added | Controls whether to write statement summary records evicted by LRU to the statement summary log after statement summary persistence is enabled. The default value is `OFF`, and this variable is read-only for TiDB Cloud Essential and Premium. | + ### MySQL compatibility * Dumpling supports exporting data from MySQL 8.4 by adapting to the updated MySQL binary log naming. [#53082](https://github.com/pingcap/tidb/issues/53082) @[dveeden](https://github.com/dveeden)