【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v5.4.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
数据Sink到Kafka, 使用open-protocol协议，当分发器配置dispatcher ="table"时，表级DDL会广播到每个Partition（个人理解当dispatcher不为table时广播是合理的，当为dispatcher为table时，表级的DDL应该和数据一样发送到对应的Partition）,现在为保证DML>DDL>DML的执行顺序，保证DDL只在处理数据的Partition执行，需要知道当分发器配置dispatcher ="table"时，根据Scheme名和table名做Hash计算的算法。
当分发器配置为 dispatcher = "table" 时，根据 Schema 名和 Table 名做 Hash 计算的算法如下：
-
将 Schema 名和 Table 名拼接成一个字符串，中间用点号
.分隔，例如testdb.testtable。 -
对拼接后的字符串进行 Hash 计算，得到一个 Hash 值。
-
将 Hash 值对 Partition 数量取模，得到一个 Partition 编号。
-
将数据写入对应的 Partition。
因此，当使用 dispatcher = "table" 时，表级 DDL 会被广播到每个 Partition，但是只有在处理该表数据的 Partition 才会执行 DDL。这是因为在 TiCDC 中，DDL 事件是通过 TiDB 的 Binlog 发送到 TiCDC，然后再通过 TiCDC 发送到 Kafka。在发送到 Kafka 之前，TiCDC 会根据分发器的配置将 DDL 事件分发到对应的 Partition，但是只有在处理该表数据的 Partition 才会执行 DDL。这样可以保证 DML>DDL>DML 的执行顺序，同时也可以避免在不需要执行 DDL 的 Partition 上执行 DDL，提高了处理效率。
您好，根据提供的算法，算出来的Partition不对呢。帮忙看下JH_150167.at_product_cha_act （格式dbName.tableName），24个partition, 消息会发送到那个partition呢，另外Hash会出现负数怎么处理的呢？
您似乎在描述与 TiDB 的配置及其与 Kafka 的数据接收器集成相关的问题。 具体来说，您提到当分配器配置为 dispatcher = “table” 时，表级 DDL（数据定义语言）语句正在广播到每个分区，这不是预期的行为。
为保证DML（Data Manipulation Language）操作的执行顺序先于DDL操作，并限制DDL语句的执行在处理数据的特定分区，需要了解dispatcher设置为“table”时使用的hash计算算法 . 看来该算法是基于架构名称和表名称的。
如果您对此问题有任何具体问题或需要帮助，请提供更多详细信息或澄清您的疑虑。
是的，我希望达到的效果是，当分配器配置为 dispatcher = “table” 时，表级DDL语句只执行在处理数据的特定分区，不希望在每个分区都执行一次。所以希望了解dispatcher设置为“table”时使用的hash计算算法，分区接收到DDL时进行hash计算得到分区编码，是处理数据分区则执行DDL, 否则不执行DDL。
在 TiDB 中，当 dispatcher 配置为 dispatcher = “table” 时，用于确定 DDL 语句分区代码的哈希计算算法取决于表使用的分区方法。 TiDB 中有不同的分区方法，包括范围分区、散列分区和列表分区。
Range Partitioning：如果表采用范围分区的方式进行分区，则不直接使用哈希计算来确定分区码。 相反，分区代码是根据为每个分区指定的值范围来确定的。 仅当分区的值范围与 DDL 语句中指定的条件匹配时，才会执行 DDL 语句。
Hash Partitioning：如果表是用hash分区的方法分区的，则通过hash计算来确定分区码。 分区码是根据DDL语句中指定的分区键的哈希值计算得出的。 如果计算出的分区码与当前正在处理的分区的分区码匹配，则执行DDL语句； 否则不执行。
List Partitioning：如果表是用list partitioning 的方式分区的，则不使用hash 计算来确定partition code。 相反，分区代码是根据为每个分区指定的特定值来确定的。 仅当指定的值与 DDL 语句中指定的条件匹配时，才会执行 DDL 语句。