另外在项目测试中，看到一个例子。对某列比如ID，使用hash partition分区表也能有效均衡，插入效率高，但是是否符合业务，需要评估适用性。
10 天前
1，PRE_SPLIT_REGIONS = 16,有点大，先设置为4试试。 2，tidb_scatter_region是否设置为on，如果没有设置为on后truncate表，会自动重建一次。
11 天前
如果只论性能，不讲是否多副本、并发、数据量、sql类型等因素考虑进去，那就是对自己的dba和架构师生涯不负责任。上面很多老师都讨论了，不提。
除了上述点，tidb具备天然raft三副本、高可用-单节点故障基本不影响应用访问、故障自愈、htap、onlineddl、存算分离、云原生、基本上业内最好的弹性扩缩容，每一点都可能成为选择的原因，甚至拯救职业生涯。 
祝好运。
祝好运。15 天前
典型tikv遇到无法访问原因：
1，IO能力不足，写崩了；看IO的情况，临时解决方案是平均IO。
2，内存不足，OOM；查看dmesg -T；如果确有其事，
在耗内存的地方，session设置变量—把水流开关拧小；减小chunksize tidb_max_chunk_size；减少executor_concurr和dist_sql_concur的并发;tidb_index_lookup_size减小索引读；慢慢，稳稳。
3，上述确认是问题：简单粗暴的办法是加内存，换nvme。
15 天前
有比较硬的办法。
1，scale in force
这一步tiup里面会删除。
2，tiup pd-ctl:v8.1.0 -u <pd_addr> unsafe remove-failed-stores storeid https://docs.pingcap.com/zh/tidb/v8.2/online-unsafe-recovery
这一步pd里面会进行删除。
注：如果pd说正在恢复什么的，重启pd。生产慎重，非业务时间进行。
祝好运。
17 天前
17 天前
600T？看来得试试v8的pd的调度组件了。
https://docs.pingcap.com/zh/tidb/stable/tune-region-performance#通过-active-pd-follower-提升-pd-region-信息查询服务的扩展能力
19 天前
哪位大佬可以提提性能。
20 天前
tiup cluster display 一把，把慢的sql执行计划拿出来看下；语句分析看下。blockcache配多少也可以说下。
20 天前
没有更多内容了