当前sql直接好像没有做好资源隔离，导致一个慢sql查询占用了所有的kv资源，使得其他的数据库操作受到资源影响。 在mysql中，有参数innodb_concurrency_tickets限制一次CPU时间获取5000条记录，然后执行其他SQL，这样就不会有一条SQL执行其他SQL都被拖慢的情况。 tidb是不是也应该要做类似的功能，否则一旦线上出现了一两次慢查询，整个集群都收到很大的影响。
tidb现在是会拖累整个集群
可以看下
测试环境可以先跑下，你也可以搜索下其他人遇到的问题
了解下大致的情况~
慢sql排查是一方面，要尽量避免。但是当前这种情况，只要出现一次慢查询，在慢查询执行期间，整个系统受到大范围影响，这个太苛刻了。
1 个赞
慢SQL会拖垮整个tidb集群的
定义sql为high priority,是表示它会进入storage read pool或unified read pool的high区呢？
这种就靠限制资源使用，还有超时机制来搞定，上线前的SQL审计
我的意思不是单独解决这一个sql的问题。是不同sql要做资源隔离的设计，按照当前的设计，手动执行一条复杂查询，就能把数据库拖死。
我认为这是一个很大的缺陷，官方要出方案去解决这个问题，类似mysql之类的解决方案，不能让大的事务长期占用所有的系统资源。希望能在后续版本中看到它的改善
我理解，例如内存的限制：
跟你说的限制类似么？
还有https://pingcap.com/zh/blog/unified-thread-pool
这是类似加入了优先级和类时间片轮转方案，目前已经在tikv中包含了。
这的确是个值得关注的问题
任何数据库都怕低效SQL。有点一个就可以让数据库资源耗尽。
所以在大厂，上线前要审核，就是这个道理。
oracle数据库都不一定能抗住一个烂SQL，mysql虽说有这机制 照样扛不住， tidb有调整tikv并发的一些相关参数比如tidb_distsql_scan_concurrency、index_lookup_concurrency等，评估有影响的大SQL可以降低这些参数值。另外你的集群配置什么样？什么样的SQL把集群拖垮了，可发出来看看
1 个赞
一条sql 执行过慢 可能有多中原因造成的，如果tidb自动对sql的进行限流或限速，给其他sql让路
那么重要的业务sql异常 将无法第一时间知道和分析。需要做一个平衡。
个人觉得这个问题目前可以通过sql审计，超时机制来设置
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。