diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index cabcd5115dbf2..473dbd0dbb52d 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 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 fd387ab59820b..b88ed8f7688df 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -15,7 +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: +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 d683c76dfd155..bb47f82f9e6d0 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. +> - 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 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..e945e8a243b72 --- /dev/null +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -0,0 +1,112 @@ +--- +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**: July 16, 2026 + +**Applicable TiDB Cloud plan**: {{{ .essential }}} and {{{ .premium }}} + +**TiDB X kernel version**: `TiDB-X-CLOUD.202603.1` + +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`: + +- `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](https://docs.pingcap.com/tidbcloud/sql-statement-modify-column/?plan=premium). + +### Observability + +* 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). + + 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). + +### 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/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) + + 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/tidbcloud/sql-statement-create-index/?plan=premium#partial-indexes-new-in-v857). + +## 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. 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) + +* 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)