一、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 不支持外键约束。若源端使用了外键，迁移后参照完整性需由业务层保障，建议同步保留外键列上的索引以维持关联查询性能。
6. 存储过程/自定义函数/触发器：TDSQL Boundless 对存储过程、自定义函数、触发器灰度支持，详见 MySQL 兼容性。若需要开启功能，可联系 腾讯云技术支持 确认。
七、从 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，也支持二级分区）。
改造只涉及建表语句，业务 SQL 无需修改。建议在大规模数据迁移前预先将大表改造为分区表，后续运行更平稳，详见 分区表实践教程。
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 不支持外键约束。若源端使用了外键，迁移后参照完整性需由业务层保障，建议同步保留外键列上的索引以维持关联查询性能。
8. 存储过程/自定义函数/触发器：TDSQL Boundless 对存储过程、自定义函数、触发器灰度支持，详见 MySQL 兼容性。若需要开启功能，可联系 腾讯云技术支持 确认。
9. Sequence：TDSQL Boundless 当前未提供 CREATE SEQUENCE 能力。若源端使用了 SEQUENCE，可改为使用自增列，或由业务侧发号器（雪花 ID / UUID / 号段服务）生成。