关注 看GitHub上已经有pr了，这解决速度够快！

tikv不能join，join的活只能tidb搞或者tiflash。tidb只能把一些过滤条件下推给tikv，然后tikv过滤以后返回给tidb，然后tidb再join。 如果说你俩表join，不没有过滤条件，你试试，就是得oom

你看看你的这俩选项配置的位置对吗？ 另外，去tikv的节点上看看 last_tikv.toml 看看这里的配置，这里面的是所有tikv上次启动的配置，你看看你改的这俩有没有改掉。

小表广播这个事儿就是分库分表的东西，分库分表因为表的数据分散在各个分库里面，如果想执行join，把小表放在各个大表旁边，直接就地join了。节省很多时间。 但是tidb是个分布式数据库，表是以region为单位分散在各个节点的，我理解tidb还不支持join下推，也就意味着即是说2个region的数据属于join的两张表，在同一个tikv上，tikv也不能直接就地计算。 join这个事儿只能tidb把两边的数据拉上来（没有tiflash的前提下），在tidb计算。 如果说想用类似小表广播的功能，缓存表是一个选项。缓存表是把小表缓存在tidb节点，这样join的时候各个节点只需要拉取大表的…

follower read 每次读取都需要去主节点来一次read index read，虽然来这么一次不交互什么数据，但是一次grpc的耗时也是多一次耗时。 stale read如果用在快速提交的场景中，直接从节点自己就搞定了。相对来说速度会快很多。

理解的很透彻，总结的很到位。 我认为stale read的存在是有意义的，比如说我的业务就是很简单，就都是小事务，也不需要读实时数据，那用stale read就很好。这个事儿还是看各自的业务场景，选择性越多越灵活，总有一款适合你。当然选择性越多越不容易掌握。 傻瓜式的没有一个选项的最省心，这就要求数据库本身很智能，能根据业务需求调整出最佳性能。

各种各样的解压玩具

擅长解决tikv的问题，帮助了一些，也没个统计。最近回答的比较少，因为论坛上没多少新问题了

向大佬们学习！希望能看到一些tiflash介绍的文章

我司节奏比较慢，目前主要集中在5.4版本，6.5的刚露头，7.x的几乎没有

看看下面这两篇文章有没有帮助。 https://docs.pingcap.com/zh/tidb/v4.0/troubleshoot-write-conflicts https://docs.pingcap.com/zh/tidb/v4.0/troubleshoot-lock-conflicts

region 太大的话，扫描比较慢。tikv的coprocessor扫描是以region为单位执行的。如果说一个表共960的数据，96M一个region，那么就是10个region并发扫描。 region size越小，并发扫描的线程数越多。速度越快。 但是换个角度，region size越小，tikv内部需要管理的元信息越多，占用的tikv的内存也越大，同时raft选举、心跳之类的元信息也越多，不利于整个集群的总体容量增大。 还有一点就是热点问题，如果说region越大，大量的写入越容易集中在一个region，然后这一个region挪到哪个tikv，哪个tikv的cpu就高很多。反之r…

破案了，没有锁也能做到最终一致，就是先开个事务，然后记录binlog，然后dump数据。 [image]

你看看是不是和我贴的命令不一样，我贴的是 tiup ctl pd 如果还不行，就呼叫tiup的专家来看看。我不怎么用tiup

tiup的命令我不太熟悉 你试试这样行么: tiup ctl pd -u http://127.0.0.1:2379 store 其中ip换成你的pd的ip

pdctl store 就看到了，所有的tikv信息就都列出来了。里面有个store_id

pd的这个自动调度应该是考虑了磁盘占用率和region的读写量，但是cpu使用率没有考虑。另外你这个资源确实如虾总说的资源那么点，就2c。查哪个节点的region，这个节点的cpu就搞起来了。你这个优化意义也不大。 如果非得要优化的话，试试调一下region weight。降低一些这个高cpu的节点的region和leader数。 pd-ctl store weight store_id leader_weight region_weight 例子： pdctl store weight 1 0.8 0.8

上面，复制格式化sql或者复制原始sql

就是用的replace，这样就可以了。看来dm有个安全模式可以这样搞。下午我再查查，看看能不能安全模式搞个备份。