TiDB-X-CLOUD.202603.1 Release Notes

Release date: July 16, 2026

Applicable TiDB Cloud plan: TiDB Cloud Essential and TiDB Cloud Premium

TiDB X kernel version: TiDB-X-CLOUD.202603.1

Starting from July 16, 2026, the default kernel version of newly created TiDB Cloud Essential and TiDB Cloud 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 @wjhuang2016 @tangenta @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.

Observability

• Support defining multi-dimensional, fine-grained trigger rules for slow queries #62959 #64010 @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 tab of the Diagnosis page in the TiDB Cloud console.

  TiDB Cloud now provides more flexible control over slow query logging. You can use the tidb_slow_log_rules system variable to define multi-dimensional slow query log output rules at the session and SQL levels, based on conditions such as Query_time, Digest, Mem_max, and KV_total. You can use the WRITE_SLOW_LOG 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.

SQL

• Support using table aliases in the FOR UPDATE OF clause #63035 @cryo-zd

  Before this release, when a SELECT ... FOR UPDATE OF <table> 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.

  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.

• Support partial indexes to reduce index storage and DML maintenance overhead #62664 #62761 #62758 #63447 #64344 @YangKeao @winoros @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.

Compatibility changes

MySQL compatibility

• Dumpling supports exporting data from MySQL 8.4 by adapting to the updated MySQL binary log naming. #53082 @dveeden

Improvements

• Enhance the parsing mechanism for Parquet files to improve the import performance of Parquet-formatted data #62906 @joechenrh
• Change the default value of tidb_analyze_column_options to ALL to collect statistics for all columns by default #64992 @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 @ChangRui-Ryan
• 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 #8690 @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 @terry1purcell @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 #65813 #66338 @elsa0520 @xzhangxian1008 @winoros
• Mitigate coprocessor request bursts for IndexLookUp queries on highly partitioned tables with local indexes to improve query stability and reduce performance spikes #67545 @gengliqi
• Optimize CPU and memory usage for INSERT ... ON DUPLICATE KEY UPDATE statements by reducing unnecessary expression buffer allocations during execution #65003 @windtalker
• Optimize the logic for timestamp advancement and leader election #9981 @bufferflies