可是column 表结构 是varchar(1024);

嗯，是偶发问题，感觉像bug，所以发出来定位一下。

技术帖子，没必要有恶意的。 世界很美好的。

大佬，这个是sysbench自动生成的表。 您可以关注下😄。

官方推荐单块TiKV机器最大4TB，是否推荐更大磁盘 随着硬件越来越便宜，磁盘越来越大，tidb还是推荐4TB，感觉有些保守了。

是的，已经让研发改了。

另，看mysql5.7介绍，comment长度是1024字符，是不是计算有问题 maxLen := MaxCommentLength // The maximum length of table comment in MySQL 5.7 is 2048 // Other comment is 1024 switch errTooLongComment { case dbterror.ErrTooLongTableComment: maxLen *= 2 https://dev.mysql.com/doc/refman/5.7/en/create-table.html#creat…

看代码是计算的 len(comment)，是按着字节截断的。 实际按字节、字符计算都没关系，但是要与官网介绍的varchar一致（charset=utf8mb4） mysql> show create table information_schema.columns\G *************************** 1. row *************************** Table: COLUMNS Create Table: CREATE TABLE `COLUMNS` ( `TABLE_CATALOG` varchar(512) DEFAU…

辛苦帮发一下 这段话的说明文档。

实际看应该是超bit了，不是超字符。

341+1个乱码 黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱…

另，您这个2048是参数配置的么？

是的，正常情况业务不需要这么长，就是发现这个问题了，怀疑是字符、字节 搞混了。

性能压测对比，应该比不过MySQL，博客中的延迟抖动、尖峰，可能跟MySQL的参数有关，可以发MySQL参数出来一起看看，再压一次。

感觉，这个还是很严重啊，天天宕机，会降低信任度。

1、tidb—>flink cdc—>ES 这样可以？ 2、tidb → mysqldump导出数据到S3（csv格式）-> Logstash → es

没做过前置性能评估， 新版本很多新特性，看自己业务是否用到，或者抽取生产AP的SQL，放到研发环境，对比升级前后性能对比。 当然如果有架构能搞定流量收集问题，也可以重放，类似美团那边流量回放。

马克围观下

申请测一下呢？ 这样也能产出成本投入情况（这个在选架构时候，通常比较重要）。