这个路径和磁盘空间没问题，而且我改了配置之后也无法执行成功

还没有，目前是这么解决了。然后我在7.5.3 的版本试了下，使用fast ddl 也能成功，我再试下其他集群验证下

嗯，成功了，我更新了下帖子

/tmp/tidb 目录空间足够，随后我修改了temp-dir 目录的配置到新的地方也无法成功执行 [图片] 目前的策略是关闭了fast_ddl ，重新执行加索引操作 关闭了fast ddl 之后重新执行成功 [图片]

通过配置AUTO_ID_CACHE = 1 实现了 非聚簇索引的自增id 的连续 Create Table: CREATE TABLE `data_630001t` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `flowid` bigint(20) DEFAULT NULL, `dataid` bigint(20) DEFAULT NULL, `thirdId` varchar(32) NOT NULL DEFAULT '', `title` varchar(100) DEFAULT NULL, `content` mediu…

我图中的情况跟你说的不是一个场景，我那个是连接到tidb01 节点上，然后一直insert ，但是id 是呈现了1,3,5 这种，并不是预期中的1,2,3。 但是当我把表改成了 聚簇索引表，插入的id 就是连续了

它应该是每个tidb-server 预分配一段id， 但是同一个tidb-server 写入的应该是连续的才对吧？

就是等待pd 滚动重启成功，只是这个过程比预期的时间更久一些。升级过上百次第一次遇到过这个情况

升级成功了

[图片] [图片] 看着也还好，会是跟这个sid 是唯一键有关系吗 ？导致写入的时候耗资源

针对问题3： 使用ts 配置需要下游消费端进行排序，否则下游最终数据会有错乱。 现在想确认下，使用partition=“column” 能否起到类似 index-value 的效果，提升消费的并发并能保证数据一致性？

版本的问题跟他们确认过：v2.4.1 ，我创建的语句如下 –sink-uri="kafka://xxxxxx:9092/tidb_xxxx?protocol=canal-json&kafka-version=2.4.1& [图片] 请问你们是如何解决这个问题的 ？

kafka 是疼讯云的，他们不给改配置

从集群的现象来看，不是热点写的问题。其实其他tidb业务好多表都是从mysql 直接迁移过来的，都是用的auto_increment, 实际上没有太明显的热点问题。 这个图是当前集群的热点状态，我觉得是毫无压力的。可能主要还是compaction 的问题 [图片] 上面你提到的参数我也从4 改到8了，这个效果不是十分理想 [图片]

这个集群写入才两三千qps ，现在的性能我觉得是不符合预期的，这点并发量就让业务改代码不合适。 我们另外一个集群每天单表(宽表)写入十几亿，qps 在3w 左右。 开始是批量写，tikv cpu 达到接近2000% 。后来改成单条写，qps 高峰期 4w 左右。tikv cpu 稍微降下来基本都是1500% 以下，但是tidb cpu 又干到2000% 多。下周我还得发个帖子研究下怎么优化

老哥请看猫老师的回复。我调整完有效果过来反馈

tikv cpu 持续保持在700% 左右，高峰期能达到1500%，这个看着还是有点担忧所以来深究下具体原因。 感谢支持

好的多谢。 其实我们另外一个集群也有这种使用场景，每天写入量挺大，每天也在一直删除。但是没有出现这个情况。我先调整下这个参数试试。