【你目前使用的版本】 V8.5.4 【最需要 v8.5.7 的哪些新功能】 SQL能力和稳定性 【还有哪些产品需求】 资源隔离，限定性隔离（少量资源可持续运行，直到运行结束产生结果）

不太好，会导致region对数据的拆分会出现问题了

多弄点资源

雪花算法在 TiDB 仍然会有热点存在，最好使用 AUTO_RANDOM AUTO_INCREMENT 可以理解为自动递增的信息，和传统数据的方式类似。这个和雪花的模式差异较大，不可混用。 否则，同一个表同一个主键又是 1 - 1000，也有可能是 999xxxx1011 , 这种跳跃可以接受么？

怎么改的，有没有详细的信息可以分享下

[image] [image] 凑个热闹，嘿嘿，居然错了一题

慌个什么，我这8.5.4

生产都上了，挺好的，很稳定

习惯就好了，当信息足够大的时候，压根就看不完就会放弃了

创建个新表，把数据搬过去就行了，看看效果在决定保留哪个 就是浪费点空间，可以的

这么多人打卡的么

DB 客户端直接执行耗时约 100ms，Java 应用调用耗时 10s~300s，升级前应用执行均在 300ms 内 DB客户端 和 Java 应用采用了不同的 JDBC 版本？是否有应用官方提供的版本？ 最好能提供 DB 直连 和 JAVA 应用请求的详细 SQL 和执行计划数据进行对照

感谢分享～

得参考限制和要求咯 [image]

lock_table 里面是什么内容？

把认证信息丢AI 界面，让 AI 看看，或许就有答案了

其中有一台 tidb 是owner，如果这个节点重启，会有另外的节点升级成owner ，可以试试

TiKV 和 TiFlash 本身就是两种引擎，如果需要在 TiDB完成数据聚合没问题，但是只能选某个引擎完成所需的数据获取。 最好的办法，就是打宽，放 tiflash ，而不是做 Join

查下这个表相关的 Region 的Key 和 Value 的版本数量，如果和实际 count 数值差不多，说明回收已经完成了。否则，就先想办法 compact 回收掉哪些被标记的 Key。 这个操作会十分影响稳定性，建议在不繁忙的情况下，手动处理。