愿TiDB越来越好！！！

我的理解，这搞个id, date日期联合索引可以提升很大吧 全索引排序

找到对应的改下文件里面的create语句 先导入进去 ？最后再rename 过去？

或者netstat 过滤一下 看看真正建立的连接有哪些，感觉直接查应该是整个集群的连接数， 下面的curl拿到的应该只是单个对应的连接数。 再或者看下监控里面连接数的取值是哪个

多看报错信息，百度一下或者专栏搜索一下 很多相似的

我觉得像这种删除会很多的，可以在业务设计初期就做好，类似于冷热数据分离，物理分表，到时候直接 truncate表，不然到时候磁盘涨的太快，删除又不释放很容易出问题

同意楼上的，你可以看下对应你觉得有问题的面板的计算公式拿的，按道理来说metrics都采集到了，加工可能出现问题

统计信息这些都收集正常吗 ？

结合场景来看吧 如果本身数据量也不大 直接主从mysql也行还省成本 如果大数据量 可以考虑TiDB测试看看

这里面分析的sql会不会对数据库本身造成压力

[image] 我觉得pointget 更多强调的是返回一行数据，一条 跟回不回表没有直接的强烈关联

部署一个新集群 数据迁移过去，做好回滚方案

同等一个结果

我理解是正常吧 不然那提单表 3节点raft 挂一个 按照这个来说岂不是集群不能用了 那高可用不就不存在了？

楼上说的真可以trytry https://docs.pingcap.com/zh/tidb/stable/dev-guide-third-party-tools-compatibility#默认不允许修改列的-auto_increment-属性

rebuild

看日志报错 根据报错内容排查

摆摊卖煎饼

就简单几个核心逻辑 备份 然后扫描文档判断文件要不要删除就好了