十年磨一剑

SQL优化是重中之重，一般在执行之前先看一下执行计划，根据执行计划调整SQL语句，其次，考虑事务型逻辑，比如单条插入value和一次性插入values,区别会很大，毕竟有MVCC机制，最后，考虑SQL语句本身的逻辑性，尽量避免全表扫描和笛卡尔积的出现

权限都是没问题的，root和tidb用户的权限，NFS文件夹的权限都设置过 报错原因就是TiFlash节点没挂载NFS磁盘

最后的最后，缩容了那个有问题的TiFlash节点，tiup cluster clean 了以后，重新跑，恢复完成。额

挂载了tiflash好了，但是恢复到33%左右，把其中一个TIFLASH节点直接干报废了。。。然后又报错了， 看tiflash日志，没有异常日志，唉… 坎坷的BR之旅…

好的，我试下挂载一下试试

新集群配置如下： [f3c90fed42b60727582460aeedb357d]

就是老集群如果有tiflsah数据，备份的时候会把tiflash的数据也备份进来么？

tiflash没挂啊

各位大佬，上述的问题，我有几个疑惑： 第一： [BR:KV:ErrKVDownloadFailed]download sst failed\n No such file or directory 这个说的应该是每个tikv节点的NFS挂载目录对不，那找不到的目录(No such file or directory)是指什么？？ 第二： 请注意两边挂载目录不一样，老集群备份使用的挂载点是/br 新集群挂载点是/data 这个自己创建的本地目录应该没什么关系吧？NFS目录不乱就行吧

【你有用 Deepseek 做过数据库选型参考吗？】有 【你问的问题是】HTAP类型的数据库的优缺点 【准确率如何？】高 【回答截图】 [1739935000640] [1739935085889]

磁盘、I/O、延迟、changefeed 关键词在此

解决了，群里大佬给的方案，tidb-deploy/alertmanager-9093/scripts/run_alertmanager.sh的脚本里看看监听地址是否是0.0.0.0，如果是，先改成对外实际IP，9093和9094都要改，然后启动节点，最后检查ip addr看看是否有私网地址，没有私网地址就会一直报上述错误。

解决了吗？和你报错一样

.sst就是KV键值对数据，看下rockdb就知道了 https://docs.pingcap.com/tidb/v8.4/rocksdb-overview 在 TiDB 中，.sst 文件（Sorted String Table 文件）是 RocksDB 用于持久化存储数据的关键组件。RocksDB 是一种高性能的嵌入式键值存储引擎，采用 LSM-tree（Log-Structured Merge-Tree）架构。以下是 .sst 文件生成的基础和过程，以及 RocksDB 在数据持久化和检索中的作用： .sst 文件的生成过程 数据写入：当用户向 TiDB 写入数据时，数据首先被记…

tot_proc: 40.4s, 你TIKV有什么瓶颈么？ cop_task 的总处理时间怎么这么长？

你主键是是创建主键时自动创建的聚集索引吧，会不会执行计划是全表扫描

开源社区、分布式、节点任意扩缩容

大部分是自动化运维，因为有监控平台，报警后，登录tidb后台，再查询报错类型和原因，手动处理并优化