TiDB 资源管控特性 提供了两层资源管理能力，包括在 TiDB 层的流控能力和 TiKV 层的优先级调度的能力。两个能力可以单独或者同时开启。将用户绑定到某个资源组后，TiDB 层会根据用户所绑定资源组设定的配额对用户的读写请求做流控，TiKV 层会根据配额映射的优先级来对请求做调度。通过流控和调度这两层控制，可以实现应用的资源隔离，满足服务质量 (QoS) 要求。
你觉得 Resource Control（资源管控）这个新特性怎么样?
优点有：
1.
2.
3.
缺点有：
1.
2.
3.
可以从产品的实现，资源管理的颗粒度、产品使用的体验、易用性、理解等展开写一下.
按要求留言参与讨论，获得 30 积分&经验值！水贴不授予积分
2024.8.16 -2024.8.23
Resource Control（资源管控）特性好
压榨最后一点硬件资源，适合毛坯用户 
Resource Control（资源管控）特性肯定是好的，我自己的实践证明，可以显著提高在资源不足的情况下的系统稳定性。
但也有缺点：
1，读写RU不能分开设置，这两个RU的上限一般不会一致，比如一个系统读ru的上限在1000，写在3000，如果这个用户只读，你按总量给他4000ru，其实就没有限制住他的读取。
2，tikv和tiflash对ru的消耗不同，也不能分开设置。这就导致在tikv上读取ru是合适的，到了tiflash上就会显著变慢，必须在资源组上加brustable。
3，缺少tiflash的ru估算。现在读写都是针对tikv的估算。tiflash的ru用量估算是缺失的。不过tiflash要估算的话，可能还涉及到mpp模式和非mpp模式的区分，这两个ru估算出来的上限应该也是不同的。从精准控制不超出系统极限的角度可能又是需要的。
功能是挺好的，越来越多的用户为了节约资源将多个小业务合并在一个tidb集群中，希望降这些用户资源隔离的更加独立些相互不受影响
资源隔离，精细化管控，挺好的
好，可以做资源的隔离和控制，对于降本和稳定性有帮助
不适用，几乎没有用大部分生产环境
如果能实现ai控制，根据整个集群的资源自动调节各个帐号的资源使用上限就完美了。
个人愚见，资源管控特性的有效实施依赖于正确的配置和管理。如果配置不当，可能会造成资源浪费或者无法达到预期的隔离效果。此外，资源管控可能会增加系统的复杂性和管理的难度。
资源管控和设计和方向是对的，一步一步来完善，希望可以在可视化和易用性方面有更多的提升
版本还没有升到，升到了试一下。
功能挺好的，就是感觉使用不够便捷，如果操作集成在Dashboard就完美了
可以控制资源的运行占用，稳定集群有啥不好的？
但是，RU 的评价和治理模式比较粗狂，不够贴近业务，不够简单，使用起来会有一些复杂。
不太清楚细节或者配置的小伙伴，会觉得很难搞
控制能力不足：从测试来看，控制TP业务还可以，但是控制略带有AP查询（如排序，聚合等）的业务能力不足（不容易控制住），往往都是这种带有AP类的查询才导致的故障，如何理解资源管控 (Resource Control) 中的RU
RU概念难以理解：线上运行后再根据运行调整RU，这个调整的归属很难把控，到底是运维层面的DBA调整还是开发人员调整？DBA不懂业务，容易出故障（比如遇到月批、秒杀日等资源占用会突增，控制了资源导致业务受影响，但是DBA不熟悉业务），开发人员不熟悉RU的概念基本也是放到最大来调整。
限流策略落地难：参考这里：Runaway Queries在故障处理情况下存在的问题
更倾向于cgroup类的隔离方式。
资源隔离，精细化管控，挺好的
目标是好的，但是现在的指标还不太容易衡量用户行为，需要更精细化的指标
目前还没有用上，这个需求最近也是越来越强烈，各个研发组之间争抢资源，sql脚本的不统一、不规范，在一个集群中不同用户因sql语句不当造成事故。下一步经过分析后根据用户限制RU。
将硬件资源的使用率最大化，奉行不浪费的原则…