TDSQL Boundless 兼容什么数据库协议？
TDSQL Boundless 与 TDSQL MySQL 比较，有哪些优势？
随着业务发展与数据量增长，单机 MySQL 面临硬盘、内存、CPU 等硬件上限。单纯升级硬件不仅成本高，也无法从根本上解决扩展性问题。业界通用的解决方案包括两类：引入 TDSQL MySQL 分库分表方案与引入分布式数据库方案。
TDSQL Boundless 和分库分表 TDSQL MySQL 相比优势包括：
弹性扩展能力更强：TDSQL Boundless 是对等架构，每个节点都可以承担读请求与写请求，在资源不足时，可以灵活纵向调整实例规格或者水平添加少量节点解决容量问题，无需提前规划，同时支持轻松的在线缩容操作，详见 存储引擎架构与数据模型；TDSQL MySQL 分库分表（Sharding）方案属于预规划分配模式，需要在业务上线前预先规划分片数量，更适合业务场景稳定或有明确规律的场景。一旦分片数量确定后续调整很困难，扩容缩容往往涉及数据重分布与迁移，流程繁重、难以在线完成，无法适应业务快速变化与敏态需求。例如，电商大促之后，需要将多个 MySQL 实例合并为一个实例时，往往需要通过数据导出导入进行数据搬迁合并，操作复杂且耗时长。
更低成本海量存储：其一，TDSQL Boundless 采用 LSM Tree 数据结构存储数据，由于 LSM 的 Append only 的特点，避免了 TDSQL MySQL 分库分表方案默认存储引擎 InnoDB 的 B+ 树因原地更新导致频繁的随机写入产生的数据页内碎片，详见 数据高压缩比；其二，TDSQL Boundless 同时提供三副本实例与双副本实例（2个全功能型副本 + 1个日志副本）两种实例类型，成本敏感类业务可以通过购买双副本实例来进一步降低存储成本，详见 实例类型；其三，当数据规模增大、冷数据比例升高时，TDSQL Boundless 支持冷数据 COS 存储，进一步降低成本，详见 冷数据归档。
更强 MySQL 兼容性：TDSQL Boundless 的计算复用了 MySQL 8.0 代码，并支持了绝大多数用户最常用的功能，例如，包括全局二级索引、跨分片查询、跨分片更新等，不支持的功能详见 MySQL 兼容性；而 TDSQL MySQL 分库分表方案的语法与功能，例如很难支持全局索引、跨分片范围（Range）查询、跨表联合查询与分布式事务一致性等等，业务开发需深度理解数据分布逻辑，业务迁移和改造门槛高。尤其在传统行业，系统复杂、表结构众多，改造代价巨大，详见 TDSQL MySQL 分布式事务。
Fast Online DDL：TDSQL Boundless 支持无需外置工具的 Fast Online DDL ，尤其是在线添加索引时，无需全量拷贝表的数据，详见 TDSQL Boundless Online DDL 的技术演进；TDSQL MySQL 分库分表方案重度依赖外置的 pt-osc 或者 gh-ost 改表工具修改表结构，而修改表结构时，绝大多数场景下还必须全量拷贝表的数据，又慢又需要大量的额外的存储空间，成本高。
TDSQL Boundless 最大支持容量是多少？
TDSQL Boundless 的最大支持容量理论上是无限的。随着业务需求的增长，您可以通过增加更多的节点来扩展数据库的容量，以适应不断增长的数据存储和处理需求。目前，公有云上已经支持部署包含数十个节点的 TDSQL Boundless 实例。
同时，TDSQL Boundless 还提供可视化界面，用于便捷地进行水平扩容和缩容操作。同时 TDSQL Boundless 内置了自动搬迁和容量均衡功能，能够在节点间自动调整数据分布，确保系统的性能和存储效率始终处于最佳状态，且无需人工干预。
TDSQL Boundless 是否需要分片键（ShardKey）？
TDSQL Boundless 无需定义分片键，其建表语法与原生 MySQL 保持一致。TDSQL Boundless 分片机制基于 MySQL 原生的分区表，大多数情况下一级 Hash 分区表足以覆盖需求，Hash 分区打散在所有的数据节点上，均衡写入压力。
在 TDSQL Boundless 中，是否需要使用分区表？
在单机版中，分区表主要用于通过分区裁剪提升 SQL 性能和通过
drop partition 的方式定期清理数据。而在 TDSQL Boundless 分布式场景下，使用分区表的好处还包括利用多个节点的写入能力，这对于大数据量的处理尤为重要。当面临大规模数据迁移时，建议预先将大表改造成基于 Hash 的分区表。这样做可以利用 TDSQL Boundless 多节点的能力来加速数据导入过程。
如果没有预先分区，而是创建了一个单表，那么在数据导入初期，所有的写入操作都会集中在一个数据节点上，这可能导致 I/O 瓶颈。TDSQL Boundless 提供了自动分裂和数据迁移的功能，但如果表一开始没有分区，这个过程可能会比较缓慢，并且在分裂和迁移期间，副本均衡也会带来额外的 I/O 开销。
通过创建分区表，可以最大限度地发挥 TDSQL Boundless 分布式数据库的能力。这种改造的成本很低，只需要修改建表语句，而不需要对业务代码进行任何其他适配。例如，如果您的 TDSQL Boundless 实例包含30个节点，创建一个包含30个分区的一级 Hash 分区表，TDSQL Boundless 会在每个节点上创建一个主副本，从而实现副本均衡。同时，业务的增量数据会均匀分布在所有节点上，每个节点的压力也会相对均衡。
总之，为了充分利用 TDSQL Boundless 的分布式特性并避免潜在的性能瓶颈，创建分区表是一种推荐的最佳实践。
TDSQL Boundless 在读取场景中是否存在性能问题？如何确定数据分片的位置？
在 TDSQL Boundless 分布式数据库中，读取性能可能会受到数据分片和查询方式的影响。以下是两种常见的情况：
带分区键的查询：如果查询中包含了分区键，TDSQL Boundless 能够直接将查询路由到包含该分区键的具体数据分片上。这种方式非常高效，因为它避免了不必要的数据遍历，直接定位到了正确的数据节点。
不带分区键的查询：当查询没有指定分区键时，TDSQL Boundless 需要通过二级索引来确定数据的位置。这种情况下，系统会在包含该表数据的节点上进行遍历查询，这可能会导致性能上的轻微下降，因为需要检查更多的数据。
从 TDSQL MySQL 迁移到 TDSQL Boundless，需要做哪些兼容改造？
注意：
以下所列差异基于 TDSQL MySQL 官方文档，具体行为请以源库实际版本与配置为准。
TDSQL Boundless 与 TDSQL MySQL 同属 MySQL 生态，基础 DML、JOIN、子查询、JSON、Online DDL 等无需改动，改造主要集中在建表语句中的分片定义与少量对象能力上。迁移前请重点核对以下差异，更多不兼容场景可联系 腾讯云技术支持 确认。
1. 建表语句改造：源库的建表语句不能原样执行，需按 TDSQL Boundless 的建表规范调整后再执行，主要包括：清理 TDSQL MySQL 特有的分片语法、主键与分区键约束、字符集与排序规则显式化。
2. 分片键改为分区键：TDSQL MySQL 通过显式分片键做水平拆分，不带分片键的 SQL 会路由到所有分片，消耗较多资源；TDSQL Boundless 采用 MySQL 原生分区表（
RANGE / HASH / LIST，支持二级分区）打散数据热点，数据按主键自动分布，无需指定分片键，详见 分区表实践教程。改造只涉及建表语句，业务 SQL 无需修改。建议在大规模数据迁移前预先将大表改造为分区表，后续运行更平稳。例如：
-- 源库（TDSQL MySQL）：shardkey 必须写在末尾CREATE TABLE t_order (`id` bigint NOT NULL,`user_id` bigint NOT NULL,`create_time` datetime NOT NULL,PRIMARY KEY (`id`, `user_id`),UNIQUE KEY `uk_user` (`user_id`, `id`)) shardkey = user_id;-- 目标端（TDSQL Boundless）：改为 MySQL 原生分区表CREATE TABLE t_order (`id` bigint NOT NULL,`user_id` bigint NOT NULL,`create_time` datetime NOT NULL,PRIMARY KEY (`id`, `user_id`),UNIQUE KEY `uk_user` (`user_id`, `id`)) DEFAULT CHARSET = utf8mb4PARTITION BY HASH(`user_id`) PARTITIONS 8;
3. 广播表改为同步表
-- 广播表改造为同步表CREATE TABLE t_dict (`code` varchar(32) NOT NULL,`name` varchar(128) NOT NULL,PRIMARY KEY (`code`)) DEFAULT CHARSET = utf8mb4 SYNC_LEVEL = NODE(ALL) DISTRIBUTION = NODE(ALL);
4. 分布式事务：
源库跨分片写入依赖分布式事务，目标端 TDSQL Boundless 原生支持分布式事务，无需应用层做特殊处理。
TDSQL Boundless 高度兼容 MySQL 8.0，支持读已提交（Read Committed）和可重复读（Repeatable Read）两种隔离级别，详见 隔离级别。
TDSQL Boundless 事务大小限制：单行记录大小受限于
tdstore_txn_max_entry_size（默认64MB）、单事务大小受限于 tdstore_max_txn_size（默认1GB）、所有运行中事务总大小受限于 tdstore_total_running_txns_size（默认3GB）。大批量导入、大事务清理类业务请提前拆分，详见 事务限制。TDSQL Boundless 不支持 XA 相关语法。若源端应用使用 XA 事务，需改为普通事务。
5. 外键：TDSQL Boundless 不支持外键约束。若源端使用了外键，迁移后参照完整性需由业务层保障，建议同步保留外键列上的索引以维持关联查询性能。
从 TiDB 迁移到 TDSQL Boundless，需要做哪些兼容性改造？
注意：
以下所列差异基于 TiDB v8.5 官方公开文档，具体行为请以源库实际版本与配置为准。
TDSQL Boundless 高度兼容 MySQL 8.0。从 TiDB 迁移时，基础 DML、JOIN、子查询、JSON、Online DDL 等无需改动，改造主要集中在建表语句与少量对象能力上。迁移前请重点核对以下差异，更多不兼容场景可联系 腾讯云技术支持 确认。
1. 建表语句改造：源库的建表语句不能原样执行，需按 TDSQL Boundless 的建表规范调整后再执行，主要包括：主键与分区键约束、字符集与排序规则显式化、清理 TiDB 私有表选项（如
AUTO_RANDOM、SHARD_ROW_ID_BITS、PRE_SPLIT_REGIONS、AUTO_ID_CACHE、PLACEMENT POLICY）等。2. 分区表改造：TiDB 由 Region 自动分裂与调度实现数据分布，并可选用特有参数
AUTO_RANDOM / AUTO_RANDOM_BASE / SHARD_ROW_ID_BITS / PRE_SPLIT_REGIONS 等进一步打散数据分布；TDSQL Boundless 采用 MySQL 原生分区表打散数据热点（RANGE / HASH / LIST，也支持二级分区）。3. 自增列：
删除
AUTO_ID_CACHE 表选项：该表选项为 TiDB 私有语法，目标端不支持。自增分配策略由实例级参数 tdsql_auto_increment_batch_size 统一控制，不支持表级配置，详见 MySQL 兼容性。自增列必须是主键或索引前缀：此处与 MySQL 8.0 行为一致。
create table test (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` char(120) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',PRIMARY KEY(`k`, `id`));ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key
4. 无主键表：源库中未定义显式主键的表（TiDB 会使用隐式行 ID 组织数据），需改造为显式主键后迁移。
5. 表名大小写敏感：TiDB 的
lower_case_table_names 仅支持值2，即比较时不区分大小写；而 TDSQL Boundless 与 MySQL 8.0 行为一致，支持开启/关闭表名大小写敏感。请在迁移前统一应用中的表名大小写写法，避免迁移后找不到表。6. 事务与隔离级别：TDSQL Boundless 高度兼容 MySQL 8.0，支持读已提交（Read Committed）和可重复读（Repeatable Read）两种隔离级别，详见 隔离级别。
说明：
例如，在需要通过单条 SQL 语句中更新多个字段时，即
UPDATE ... SET 语句，TiDB 的 SET 子句对列引用取的是更新前的旧值（与 SQL 标准一致）；TDSQL Boundless 的行为和 MySQL 8.0 行为一致，从左到右求值，后面的赋值能够看到前面刚写入的新值 （MySQL 此处行为与 SQL 标准存在差异）。TDSQL Boundless 选择对齐 MySQL 8.0，便于业务从 MySQL 生态平滑迁移。若源库 SQL 依赖"取更新前旧值"的语义，请改写为拆分成多条语句或引入中间变量。create table test(`id` int auto_increment,`v1` int,`v2` int,`name` varchar(100),PRIMARY KEY(`id`));insert into test values (null, 100, 100, 'init'), (null, 300, 200, 'init2');-- UPDATE 语句更新数据时，更新 v2 的值时，TiDB 按照更新前看到的 v1 = 100 值进行更新SQL>update test set v1 = v1 - 20, v2 = v1 where id = 1;Query OK, 1 row affected (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 0SQL>select * from test;+----+------+------+-------+| id | v1 | v2 | name |+----+------+------+-------+| 1 | 80 | 100 | init | ## v2 = 100 为更新前 v1 的值| 2 | 300 | 200 | init2 |+----+------+------+-------+2 rows in set (0.00 sec)-- UPDATE 语句更新数据时，计算 v2 的值，MySQL 与 TDSQL Boundless 都是按照更新后的 v1 值进行更新SQL>update test set v1 = v1 - 20, v2 = v1 where id = 1;Query OK, 1 row affected (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 0SQL>select * from test;+----+------+------+-------+| id | v1 | v2 | name |+----+------+------+-------+| 1 | 80 | 80 | init | ## v2 = 80，为更新后 v1 全新计算的值| 2 | 300 | 200 | init2 |+----+------+------+-------+2 rows in set (0.00 sec)
7. 外键：TDSQL Boundless 不支持外键约束。若源端使用了外键，迁移后参照完整性需由业务层保障，建议同步保留外键列上的索引以维持关联查询性能。
9. Sequence：TDSQL Boundless 当前未提供
CREATE SEQUENCE 能力。若源端使用了 SEQUENCE，可改为使用自增列，或由业务侧发号器（雪花 ID / UUID / 号段服务）生成。
