TiDB 5.4面对业务方超级复杂的大SQL，直接Out Of Memory Quota!
而同样的SQL语句在MySQL里一点事都没有。
https://docs.pingcap.com/zh/tidb/stable/overview，TiDB有他自有的一些特性，
这些是一键扩缩容、高可用、HTAP是原生Mysql不具备的，根据场景可以选择使用哪个产品。
有些场景下为了适应分布式场景做了一些限制，可以参考楼上的建议调整一下。
1 个赞
当内存使用超过一定阈值后也能采取一些操作来预防 OOM 或者排查 OOM 原因。在 TiDB 的配置文件中，我们可以使用如下配置来控制内存使用超阈值时 TiDB 的行为：
# Valid options: ["log", "cancel"]
oom-action = "cancel"
1、资源足够增大mem_quota_query
2、看下表结构(是否有大字段)、SQL、执行计划有没有可能让返回tidb server数据少一些。
2 个赞
先调整mem-quota-query 这个试试
k8s 集群如果持久化修改 tidb_mem_quota_query 配置，这个 session 级别的，每次 client 重新登录就失效。通过 tiup bench 完全跑不下去，第二个 sql 就 OOM
我个人观点，任何东西再好也不是说无限制使用。都要有一定的规范。至今为止未见到过可以放任使用的产品。
请看阿里 腾讯也有数据库开发规范。还是要从规范角度来看待。
分布式本质上就是要解决一个节点存储量或计算量不够的问题，但却出现了同一个查询在MySQL能跑出来而TiDB跑不出来的情况，这是进步还是倒退呢？
楼主的情况我也遇到过，TiDB好处再多，如果我说服老板迁移到TiDB，然后老板要的数据给不出来，这不是打我自己的脸吗？
我也遇到过类似的问题， 个人觉得不能简单的说 mysql 跑的出来， tidb 跑不出来； 得看付出的代价； 在tidb端设置了一些限制，你如果放开的话 ，然后优化一下，也是可以跑出来的吧； 但是， 我在生产的感觉是，对于业务繁忙的系统， 超过我设置资源的大sql， 我宁愿它oom， 这样能提升我整体的稳定性； 因为很多时候， 大sql不可控的话，对业务侵入太大；
我有些不同的观点：
- MySQL单机，配置还不如TiDB集群的单独一个节点，都能跑出来的复杂SQL，在TiDB这边十倍资源的集群中还要谈代价吗？
- 我愿意跑复杂SQL，如果影响了业务，风险和后果我负责，该优化优化，该错峰错峰。但要是连结果都跑不出来，就是数据库产品该优化了。
1 个赞
非常赞同你的观点
1 个赞
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。