tencent cloud

TDSQL Boundless

DocumentationTDSQL BoundlessProduct IntroductionCompatibility NotesCompatibility with MySQLMySQL Compatibility

MySQL Compatibility

Download
Focus Mode
Font Size
Last updated: 2026-05-29 10:17:06
TDSQL Boundless is highly compatible with the MySQL 8.0 protocol. This allows you to use your existing ecosystem of MySQL tools, such as phpMyAdmin, Navicat, MySQL Workbench, and DBeaver, without modification.

Unsupported Features

DDL operations on the mysql system database
Generated Columns
Events
Tablespaces (icluding Transportable Tablespace)
Resource Groups
Foreign Keys
Partial updates of LOB data types
Multi-valued indexes on JSON data type
Spatial functions, data types, and indexes (GEOMETRY/GIS)
Full-text Indexes and syntax
Descending Indexes
REPAIR TABLE syntax
Exchanging partitions (ALTER TABLE ... EXCHANGE PARTITION)
SKIP LOCKED syntax
XA-related statements return success but do not take effect.
Group Replication
X Protocol

Differences in Behavior from MySQL

Auto-increment Columns

TDSQL Boundless offers two modes for auto-incrementing IDs:
High-Performance Mode: This mode improves performance by caching a batch of auto-increment ID values on each peer node. It guarantees that auto-increment values are globally unique, but does not guarantee that they increase sequentially across all nodes. The batch size of the cache is controlled by the parameter tdsql_auto_increment_batch_size, with a default value of 100.
MySQL Compatibility Mode: By setting tdsql_auto_increment_batch_size = 1, you can ensure that auto-increment values are both globally unique and strictly sequential.
Warning:
Risk of Duplicate Values: To prevent duplicate AUTO_INCREMENT values, the auto-increment column must be defined as a standalone primary key or unique index. If it is only part of a composite primary key, manually inserted IDs can conflict with system-generated IDs.
Unlike MySQL, the auto-increment column in TDSQL Boundless may contain duplicate values under specific circumstances. When the auto-increment column is not a primary key or unique index (such as when it is only part of a composite primary key), TDSQL Boundless cannot guarantee the uniqueness of its values. This issue occurs when manually inserted auto-increment values conflict with system-generated values. For example, when a test table t1 is created where the auto-increment column id forms a composite primary key with f1:
CREATE TABLE `t1` (
  `id` int NOT NULL AUTO_INCREMENT,
  `f1` int NOT NULL,
  `f2` int DEFAULT NULL,
  PRIMARY KEY (`id`,`f1`)
) DEFAULT CHARSET=utf8mb4;
At this point, perform the operation to write data on node 1, automatically generating data with id = 1:
-- Using system-generated auto-increment.
insert into t1(f1, f2) values(1,1);
On node 2, manually specify id = 1 and perform the write commit:
-- The user manually specified the auto-increment.
insert into t1(id, f1, f2) values(1, 1,1);
This may result in duplicate id values. Therefore, when an auto-increment column is defined, it is recommended to define it as a standalone primary key/unique index.

Storage Engine

TDSQL Boundless only supports creating and using tables with the RocksDB storage engine, and does not allow modification of the table engine. Any ENGINE clause specified in a CREATE TABLE statement will be automatically converted to ENGINE=ROCKSDB.
Note:
The Blackhole engine is an exception and can be used.

Character Sets and Collations

Note:
Starting from version 8.0.29, official MySQL changes the default encoding from UTF8 to utf8mb4.
TDSQL Boundless retains the older default of utf8mb3 (aliased as utf8). To ensure maximum compatibility and portability, we strongly recommend explicitly defining the character set when creating tables and database connections.
Item
TDSQL Boundless
MySQL (before 8.0.29)
MySQL (8.0.29+)
Default Character Set
utf8mb3
utf8mb3
utf8mb4
Default Collation
utf8_general_ci
utf8_general_ci
utf8mb4_0900_ai_ci

SQL Broadcast

TDSQL Boundless provides a /*# broadcast */ SQL hint to broadcast a query to all nodes in the instance. This is useful for commands that are otherwise node-specific. For example,
The SET GLOBAL command only sets a variable on a single node. To apply a setting globally, use /*# broadcast */ SET GLOBAL to broadcast it to all nodes.
SHOW PROCESSLIST displays the processlist for the currently connected node. To view the processlist for all nodes, use /*# broadcast */SHOW PROCESSLIST; or SELECT * FROM information_schema.processlist.

Log Output

In TDSQL Boundless, the general log general_log and the slow query log slow_log can only be output to files. They cannot be configured to output to a table via SET GLOBAL log_output=TABLE.

DDL Differences

TDSQL Boundless supports more online DDL operations than standard MySQL, including online changes to column types, character sets, and converting between partitioned and non-partitioned tables. However, unlike MySQL, less commonly used DDL operations—such as adding/dropping primary keys, adding a column with an expression as a default value (ADD COLUMN DEFAULT (a+a)), or altering tables with triggers—are not supported online in TDSQL Boundless. If errors occur during such DDL operations, disable Online DDL mode by executing set tdsql_use_online_copy_ddl = 0 before retrying.
For more detailed differences, refer to the Online DDL Notes.
Note:
If errors occur during operations such as adding/dropping primary keys, adding columns with an expression as a default value (ADD COLUMN DEFAULT (a+a)), or modifying tables involving triggers, disable Online DDL mode by executing set tdsql_use_online_copy_ddl = 0 before retrying. Note that disabling Online DDL mode will lock the table and block writes to it during DDL execution.

Note:

Note:
It is strongly recommended that when updating data via the INSERT ... ON DUPLICATE KEY UPDATE statement, you adopt a uniform writing style by consistently omitting the primary key. This ensures a consistent locking order across all transactions.
When MySQL InnoDB executes an INSERT ... ON DUPLICATE KEY UPDATE statement and detects a primary key conflict, it immediately switches to performing an UPDATE operation. It does not lock the unique index on the table to verify the unique index constraint.
To improve write performance, TDSQL Boundless enables a batch write optimization mechanism by default (tdsql_stmt_optim_batch_upsert = ON). Even after a primary key conflict is detected, this mechanism continues to lock the table's unique index to verify uniqueness. If concurrent SQL statements are written inconsistently, resulting in opposite locking orders, deadlocks may occur.
A deadlock is triggered only when all the following restrictions are met simultaneously:
A table contains both a primary key and a unique index.
Multiple INSERT ... ON DUPLICATE KEY UPDATE statements concurrently operate on the same record.
SQL statements are written in a mixed style (some statements specify the primary key PK for writing, while others do not).
For example, create a test table t1 with a unique index on the uk_col field:
CREATE TABLE t1 (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  uk_col INT NOT NULL,
  col VARCHAR(255),
  UNIQUE KEY idx_uk (uk_col)
) DEFAULT CHARSET=utf8mb4;
INSERT INTO t1 VALUES (100, 100, 'init');
During concurrent writes, when Transaction A updates with the primary key id field and detects a primary key conflict, it locks the primary key first and then the unique key. In contrast, Transaction B updates without the primary key field, locking the unique key first and then the primary key. This opposite locking order can potentially lead to a deadlock:
-- Transaction A: With primary key id → Locks the primary key first, then the unique key
INSERT INTO t1 (id, uk_col, col) VALUES (100, 100, 'session a') ON DUPLICATE KEY UPDATE;

-- Transaction B: Without primary key id → Locks the unique key first, then locates the primary key.
INSERT INTO t1 (uk_col, col) VALUES (100, 'session b') ON DUPLICATE KEY UPDATE;

-- Transaction A and Transaction B execute with high concurrency → A deadlock may occur.
Solution
Unified SQL Writing Style (Recommended): Ensure that all INSERT ... ON DUPLICATE KEY UPDATE statements uniformly omit the primary key field. This ensures all transactions follow the same locking order and avoids mixing styles that include or omit the primary key.
Disable BATCH Write Optimization: Set the system parameter tdsql_stmt_optim_batch_upsert to OFF. This reverts to a row-by-row checking mode, terminates early upon primary key conflict, and stops locking secondary indexes, aligning its behavior with MySQL InnoDB.
Note:
Disabling the system parameter tdsql_stmt_optim_batch_upsert may impact batch write performance in multi-index scenarios. It is recommended to evaluate your business workload before proceeding.
Changes take effect only for new connections. You must reinitialize the connection pool.

Other Differences

SHOW VARIABLES; and SHOW GLOBAL STATUS; display status information from the currently connected compute node. The information displayed may vary when different compute nodes are connected to.
LOCK TABLE-related statements do not lock tables or block business reads and writes. Consequently, operations that rely on LOCK TABLE may be limited, such as the mysqldumper export tool.

Gray Feature

The features listed below are considered Gray Features in the current version. Please use them only under specific conditions and according to the provided instructions.
Note:
Each Gray Feature has its own independent toggle and default value. To enable/disable a feature, connect to your TDSQL Boundless instance and execute the following SQL statement (using tdsql_enable_trigger as an example): SET PERSIST tdsql_enable_trigger=ON;.
Feature Name
Switch
Default Value
Description
Trigger
tdsql_enable_trigger
OFF
Not recommended for production use.
View
tdsql_enable_view
ON
Avoid UPDATE operations on views.
Avoid ALTER on view definitions.
Stored Procedure
tdsql_enable_procedure
ON
Avoid ALTER on procedure definitions.
Function
tdsql_enable_function
ON
Avoid ALTER modifications to FUNCTION.
Previous Topic: Instance TypesNext Topic: Use Limits

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback