按理说不应该，你实际登录主机看下tikv进程的内存占用呢

1024/3*0.45=153G吧，但是你这1T内存，才部署3个tikv啊，你上面挂了多少硬盘，cpu和硬盘够的话，其实可以多部署几个tikv啊

我们的集群都是一直跑，从没重启过。。。。

storage.block-cache.capacity设置了，memory-usage-limit 根本不用设置，你的内存再大也超不过storage.block-cache.capacity的2.25倍

storage.block-cache.capacity再调小点，调整成5G看下，总内存16G，有点小了。

首先不建议tiflash节点和其他按节点混布，另外一个机器上部署3个tikv需要限制storage.block-cache.capacity参数的值，另外做好numa绑定。 我认为你现在最重要的就是先把tikv的storage.block-cache.capacity先设置下，千万别用默认值

滚动停止升级最稳妥，但是如果是lvm的话，只是扩一下目录的大小，其实在线就可以。

tiflash加分区，老大难啊

【在数据库运维时，DBA 们会做什么事情来提高数据库安全性？如权限分发、灾备等】 访问控制、权限管理、敏感数据保护、定时备份、监控维护 【哪些是你常用到的数据库安全特性？如访问控制、传输加密等】 访问控制、权限管理、定时备份、监控维护

表和索引不一致吧，看下两个sql的执行计划吧

create_time也输出下看看

这个没找到啊。。。

一般都是晚上业务低峰期收集，然后有特别大的表的话， 写定时任务手动收集

dm是从mysql到tidb，上下游都是mysql，直接用mysql的主从不完事了

需要打label了，防止3副本都存放在一个物理机上，如果出现这种情况，这个物理机宕机了，集群必挂，所以打label保证3副本每个副本放在一台物理机上即可。

dify部署过了已经是用默认的weaviate向量库了，可以换成tidb带向量功能的版本，不换可以用。。。

这就是你的 [image] 这个dml的sql阻塞了你的 [image] ddl语句啊 找到对应的会话，杀了，ddl就执行过去了

【你看过哪些让你眼前一亮的架构案例或设计思路？】 polardbx文档上的动态扩缩容涉及思路其实不错，只是做的也没那么好 【所在行业的场景对系统架构有哪些要求？】 稳定压倒一切 【你认为 TiDB 是否能让您现有的架构在满足业务需求的同时更加简洁、高效和优化？】 应该都在商业版的功能里面，享受不到啊

那你看下pdleader节点和两个tidb-sever节点的时钟的差异，是不是异常那台差异很大，做一下时钟同步吧