遇到查询慢的时候，首先看 tidb面板的kv_request ，看看哪个tikv慢。 然后重点关注kv面板的 grpc 类型，看看是不是 coprocessor 的很多。 然后证实了以后，去优化sql，看看是不是执行计划选的不对

3个tikv不可能缩掉的。因为就是3副本。你得大于3个tikv才可以缩。

我记得当时还有个 @东北大胖子 很活跃，最近都不怎么见了。

刚接触tidb的时候，很多问题不太清楚，当时回答问题比较给力的老师： @yilong @qizheng @h5n1

看你的tc没啥问题，那检查下operator的版本？ [image] https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/tidb-operator-overview

Answer 这个错误的原因是 PD 服务器的 join 配置中包含了一个无效的 URL。具体来说,问题出在以下配置行: --join=http://basic-pd-2.basic-pd-peer.namespace.svc:2380,http://basic-pd-1.basic-pd-peer.namespace.svc:2380,http://basic-pd-0.basic-pd-peer.namespace.svc:2380/ 错误信息指出 URL 不能包含路径,但最后一个 URL http://basic-pd-0.basic-pd-peer.namespace.svc:…

[image] 以后社区里急需积分的朋友们可以用这个回答一些问题，又能帮助论坛的其他人还能得分。社区的回答问题的知识水平迅速提高

参考这个文章，大概了解下事务： 事务提交后，数据会在 write_cf 或 default_cf 中。 所以，关键在于找到key。key 按照库名+表名+主键 编码的，格式参考： https://docs.pingcap.com/zh/tidb/stable/tidb-computing#表数据与-key-value-的映射关系 算出了key以后，再去单独的tikv节点上执行 ldb命令就可以查了。 大概扫描一个key的命令如下： ./tikv-ctl ldb scan --from 7A7480000000000000FF0D00000000000000F8 --to 7A7…

主锁删掉后，从锁紧跟着就删掉了。如果说异常了，残留了，会自动清理掉的，不会卡住。

可以看看这个，有没有帮助。

有sc的话，就在配置storage的地方指定sc就行吧。遇到了什么问题了吗？

分区表就理解成多个表就行了，一个分区一个表。然后一个表至少一个region。这样的话你就好分析怎么用能避免热点了。

这个也得看你插入的情况，如果按照年分区，但是你插入的数据都是同一年的，那其实和有没有分区就没关系了。

删列应该不会降低空间吧，因为tidb是online ddl，基本上就瞬间完成了，数据不会重整。至于gc、compact这些动作的关系是这样的：gc把过期的版本在rocksdb层执行delete(key), compact的动作是把 delete(key)和上一个版本的put(key,value) 合并后删掉。我理解删列对数据key不做任何动作，只是元数据做一些标记。

保证了一致性，有好几种方式，有一种是加锁后，取位点，开始备份数据。有一种是不加锁，取位点，开始备份，然后回放时可能会重复回放一点，用replace的方式回访就实现了幂等。最终一致。 load完成后开始sync 最后俩问题等其他人解释下吧，我理解就是binlog解析成sql后执行，什么原因导致的错误不太清楚。

https://docs.pingcap.com/zh/tidb/v8.0/auto-increment#auto_id_cache https://docs.pingcap.com/zh/tidb/v8.0/auto-increment#mysql-兼容模式 用这个，搞成1，就不cache了。然后也就不会报错了吧。 当然性能也会受比较大的影响。 你可以试试好使不 别的没办法了吧。

进步太快了！统计信息这个更新也不错，我理解统计信息只是用来指导索引的选择，没必要弄的大而全，收集的信息够用就行

不一定24小时，12小时以上吧，头天开始搞，第二天去看看基本上搞完了。就是标准的store limit =15 这种的，对业务影响比较小。

2.2t的数据如果同步一天能完成那就是正常速度。我们这边扩缩容基本上就是这个速度。