调度任务
基于执行计划的、可编排的数据分片调度任务执行框架
TDSQL Boundless 设计了一个基于执行计划的可编排任务框架，用于将多个原子调度任务组合成复杂的逻辑流程（如RG + Region 双层元数据，拓扑感知，调度策略任务，复合式任务子步骤等）。该框架的核心是一个称为 Task 的编排器，它负责解析调度目标、规划执行步骤、管理依赖关系，并依次向存储层（TDStore）下发原子指令。
如下所示，由于查询优化需求，需要将逻辑上关联的 table1 和 table2 在物理上调度到同一个节点（Node1），以减少跨节点交互。
1. 初始状态：table1 的数据分片位于 Node1 的 Region1 和 Region2 上；table2 的数据分片（Region3）位于另一个节点 Node2 上。
2. 执行分裂：框架向 TDStore 下发第一个原子任务——“分裂 RG2”。TDStore 执行完毕并上报成功。
3. 执行迁移：框架确认前置条件满足后，下发第二个原子任务——“将 Region3 从 Node2 迁移至 Node1”。TDStore 完成数据迁移。
4. 切主并合并 Region：框架下发第三个原子任务——“将相关 RG 的主副本切换（Transfer Leader）”，以确保两个 RG 的数据处于同分布状态。在所有前置步骤成功后，框架下发最终的原子任务——“合并指定的 RG。
通过此框架，复杂的运维操作被简化为一个自动、可靠的调度任务，无需人工干预每一步。
可编排的数据分片调度任务执行框架
管控调度引擎实现了一套可编排的任务执行框架，通过定义事务性子任务，使存储层只需感知KV操作原语，从而保持其语义简洁性。
该框架将复杂的调度逻辑抽象为可编排的事务型子任务。以两张表的亲和性调度为例，这是一个逻辑层面的调度需求，框架会将其分解为多个原子步骤（如分裂、迁移、切换主副本等），并确保这些步骤组成的事务要么全部成功，要么在任一环节失败时能够完全回滚。
通过这种设计，复杂的调度逻辑完全由管控层处理，存储层仅需执行简单的KV操作原语，实现了调度复杂性与存储简洁性的有效分离。
基于Cost-Estimation 的执行计划
管控调度引擎维护和更新全局资源分布状态和信息 ，计算可能的执行计划及代价 。
分布式多节点、 多数据分片场景下，面向全局资源以及读写热点分布寻找最优解。
调度规则
典型业务场景
基于TDSQL Boundless的数据感知与调度能力，我们针对典型的业务场景需求，抽象并定义了一套数据生命周期管理与放置规则策略系统。该系统能够直接响应业务诉求，智能地指导数据分片的调度与放置。
场景1：流水、账单
业务痛点：历史数据（如3个月前的子分区）占用高成本存储资源，传统方案需外置脚本定期迁移，业务访问需配置不同端口
场景 2：金融，多法人
业务痛点：监管要求不同法人数据必须物理隔离，传统方案通过改写 SQL 引擎实现，扩展性受限，且无法实现细粒度的拓扑感知。
场景 3：广告，检索
业务痛点：
分区表之间，跨表关联查询 ，具有相关性的数据尽可能放在一起 。
TDSQL MySQL（InnoDB版）支持固定形式。
无数据拓扑感知 ，无法实现。
基于当前分布式中间件架构，这一需求尚未得到很好的解决，因为该架构缺乏逻辑层面的感知能力。而在 TDSQL Boundless 数据感知能力体系中，通过构建的逻辑亲和性能力，我们可以将这些表调度到同一个节点上，从而有效解决上述问题。
基于以上几个场景，我们对相关规则进行了抽象，定义了一套生命周期管理的策略系统。该系统用于指定数据的分布位置，并确保表之间具备所需的亲和性。
实现符合通用标准的、可扩展的数据分布与亲和性调度策略系统
基于数据拓扑感知能力，实现可扩展的符合 K8s 语义的策略接口系统 ，作为驱动数据分布调度任务框架的编排输入。
结构 ：约束 constraints 由一条或多条固定格式的
key-op-values 组成。 其中，
op支持in、notIn、exists、notExists、=、!=等基于等值的和基于集合的标签选择运算符 。含义 ：创建
table_1，绑定 cross-3-idc 策略 ，该表有一主两备3个副本，在 gz_1 - 5 可用区中分布，Leader 尽量不选择 gz_3 或 gz_5 ，优先确保 zone 级别的容灾能力， 如 zone 级别容灾无法满足，则自动退化为保证 rack 容灾级别的分布。
策略示例：创建表时绑定
cross-3-idc 策略。CREATE TABLE table_1 USING DISTRIBUTION_POLICY cross-3-idc
常用副本放置规则
key | op | values |
region | "in", "notIn", "exists", "notExists" | 地域列表，如 ["guangzhou"] |
zone | "in", "notIn", "exists", "notExists" | 可用区列表，如 ["guangzhou-1"] |
rack | "in", "notIn", "exists", "notExists" | 机架列表，如 ["rack-1","rack-2"] |
host | "in", "notIn", "exists", "notExists" | 主机列表，如 ["host-1","host-2","host-3"] |
node | "in", "notIn" | 节点列表，如 ["node-tdsql3-xxx-001"] |
replica-count | "=" | 副本数量，如 ["3"] |
follower-count | "=" | RG follower 数量，如 ["2"] |
learner-count | "=" | RG learner 数量，如 ["1"] |
witness-count | "=" | RG witness 数量，如 ["1"] |
leader-preferences | "=" | RG leader 偏好 |
fault-tolerance-level | "=" | 容灾级别，如 ["zone"] |
tdsql-storage-type | "in", "notIn", "exists", "notExists" | 磁盘类型列表，如 ["CLOUD_TCS","CLOUD_BSSD"] |
策略系统核心价值
通用标准：符合事实标准， key-op-values 规范对用户友好。
语义可扩展 ：可以根据不同的业务需求，扩展更多的 PolicyOption。
数据链路全解耦 ：调度引擎独立管控，计算/存储全解耦，数据拓扑感知 + 调度任务编排框架驱动。
典型示例
对于流水、账单场景，TDSQL Boundless 通过内置策略（如3个月之前的子分区，自动迁移至冷存节点，降副本）实现自动化冷热数据分层，无需人工干预。用户只需通过 SQL 指定数据生命周期策略，系统自动识别过期数据并将其迁移至低成本存储节点。
CREATE TABLE table_1(id INT, trans_date DATETIME)PARTITION BY RANGE (TO_DAYS(trans_date) ) (PARTITION p1 VALUES LESS THAN (TO_DAYS('2022-11-01')),PARTITION p2 VALUES LESS THAN (TO_DAYS('2022-12-01')),PARTITION p3 VALUES LESS THAN (TO_DAYS('2023-02-01')),PARTITION p4 VALUES LESS THAN (TO_DAYS('2023-03-01')));ALTER TABLE table_1USING DISTRIBUTION_POLICY partition-cool-down
隐式/显式地为分区规则相同的表建立亲和性关系
隐式亲和性
在分布式数据库环境中，对于分区规则相同的表，TDSQL Boundless 引入了分区级亲和性调度机制，以优化关联查询性能并降低分布式事务开销。
如下所示，当两张表采用相同的分区规则时，系统默认认为其相同编号的分区在业务逻辑上具有强关联性（例如常在同一事务中被同时访问）。基于这一判断，调度引擎会主动将相同编号的分区调度至同一物理节点，从而实现数据本地化访问。
CREATE TABLE t1(id INT PRIMARY KEY, f1INT,f2 VARCHAR)PARTITION BY HASH (f1) PARTITIONS 3;CREATE TABLE t2(id INT PRIMARY KEY, f1INT,f3 VARCHAR)PARTITION BY HASH (f1) PARTITIONS 3;
下图左边为未启用亲和性调度时，数据分布分散，关联查询需跨节点访问，网络开销大。集群扩容时，均衡策略可能进一步打散相关数据（如将 t1.p3 迁移至新节点 node3），加剧性能损耗。
右边为启用亲和性调度后，通过调度引擎的智能编排，将关联分区（如 t1.p3 与 t2.p3 ）固定在同一节点，有效避免因扩容或负载均衡导致的数据分散，保障查询性能稳定。
显式亲和性
除了分区表的隐式亲和性外，TDSQL Boundless 还提供了显式亲和性定义机制，允许业务通过 SQL 语法主动配置表间的关联关系，实现更精细化的数据分布优化。
场景一：小表紧密关联
适用情况：有两张数据量不大的小表，业务上紧密相关，频繁做写入或关联查询，要保证在同一个RG。
配置语法：
CREATEPARTITIONPOLICYIFNOTEXISTSpp1
调度效果：系统将尽可能将这两张表分配到同一个复制组（RG）中，确保关联操作在节点内完成，消除分布式事务开销。
场景二：大表分区级亲和
适用情况：数据量巨大的表，无法将整表置于同一 RG，但可通过分区实现局部亲和
配置语法：
CREATEPARTITIONPOLICYIFNOTEXISTSpp2PARTITIONBYHASH(INT)PARTITIONS4
调度效果：系统将两张表相同规则的分区（如相同哈希值的分区）调度至同一 RG，两张表上同一时间的写入和查询没有2PC或跨节点JOIN。
