原来以为是由优先级的概念，如果有主键，唯一索引更新就不会进行拆分，但看代码目测不是这样，是主键或唯一索引更新都会进行拆分。 [image] kafka 这种拆分可以认为是要解决第 2 个问题，key 变更会被拆分到两个 partition，但 key 默认是主键，如果存在主键，此时变更应该还是在一个 partition 上，不会分发到两个 partition 上。 因此理论上，存在主键的 mq 数据源，唯一索引的更新可以考虑不被拆分。 正常业务主键都是自己生成的分布式 ID，或者 TiDB 的随机 id，可能会发生唯一索引变更，不会发生主键变更。

我们只用到了 canal-json 协议，理论上可以考虑做更细粒度的根据协议判断，而不是 sink 类型（MySQL、MQ），现在看代码好像是只用 sink 类型判断 [image]

TiDB的视频教程看完配合《数据密集型应用设计《》有奇效，原来看这本书昏昏欲睡，看完视频看这个有种任督二脉被打通的感觉

再来次深圳

先学习，楼上好多大佬介绍应用场景

线上没有特殊需求还是不会升级的

TiProxy

键盘真的挺舒服的 [6vd50r17y9bhwm56pzikl5zt4_0]

可能要限制一些回答范围，避免被滥用 语料库和使用工具的用户输入没关系，避免污染

基本上还是根据业务场景和成本选择的

TiDB Serverless

感觉只有 Serverless 这种才能比较好控制吧，自己搭的都挺难搞

TiDB 新特性系列，最近一年工作比较忙，工作上也不太接触 TiDB，刚才有人回复之前发的文章发现 TiDB 真的日新月异，比如 6.1 版本的 JoinRecord 算法又多了个新的动态规划实现，默认基本上都是走这个了，以前遇到的问题相当于没有了

学学go看看源码

今年目标： 1.2~3 个练手和中间件项目 2.继续减重并保持

河南烩面

河南大盘鸡烩面

年前过油

可以看下调优文档：https://docs.pingcap.com/zh/tidb/stable/tune-operating-system