执行复杂查询导致内存溢出OOM

【 TiDB 使用环境`】生产环境
【 TiDB 版本】v5.4
【遇到的问题】OOM

【问题现象及影响】
执行复杂查询内存不断增长直至内存溢出宕机重启,内存迅速回升,连接断开

组件的信息都是v5.4


topology.txt (5.7 KB)

tiup-tidb-Overview_2022-04-27T05_14_49.481Z.json (1.0 MB)

不知道是不是这个日志,如果不对的话各位请指点一下,需要什么信息,然后我再上传感谢

2 个赞

补充一下集群配置

2 个赞

哪些复杂查询导致的这个问题? 有没有开启问题定位,帮你先找到这些

2 个赞

没有开启问题定位,刚接入不熟悉

2 个赞

异常SQL.txt (1.7 KB) 异常SQL执行计划.txt (16.5 KB)

1 个赞

看起来都很复杂,能在业务的角度优化一下么?

1 个赞

业务角度好像优化不了了

1 个赞

看起来很复杂的SQL,有TiFlash吗?加hint在TiFlash上执行如何

1 个赞

有TiFlash hint 是啥呢?

1 个赞

READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name …]], TIKV[t2_name [, tl_name …]])

READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name ...]], TIKV[t2_name [, tl_name ...]]) 提示优化器从指定的存储引擎来读取指定的表,目前支持的存储引擎参数有 TIKVTIFLASH 。如果为表指定了别名,就只能使用表的别名作为 READ_FROM_STORAGE() 的参数;如果没有指定别名,则用表的本名作为其参数。例如:

SELECT /*+ READ_FROM_STORAGE(TIFLASH[t1], TIKV[t2]) */ t1.a FROM t t1, t t2 WHERE t1.a = t2.a;

文档如下:
https://docs.pingcap.com/zh/tidb/stable/optimizer-hints#read_from_storagetiflasht1_name--tl_name--tikvt2_name--tl_name-

1 个赞

这是改变写法,这个会在参考当中,非常感谢,除了改变写法之外还有别的方式嘛

1 个赞

以下也可以临时测试,验证一下,可以先不改代码,在数据库执行计划上做修改。

执行计划管理 (SPM)

执行计划管理,又称 SPM (SQL Plan Management),是通过执行计划绑定,对执行计划进行人为干预的一系列功能,包括执行计划绑定、自动捕获绑定、自动演进绑定等。

执行计划绑定 (SQL Binding)

执行计划绑定是 SPM 的基础。在优化器 Hints 中介绍了可以通过 Hint 的方式选择指定的执行计划,但有时需要在不修改 SQL 语句的情况下干预执行计划的选择。执行计划绑定功能使得可以在不修改 SQL 语句的情况下选择指定的执行计划。

源文档如下:
https://docs.pingcap.com/zh/tidb/stable/sql-plan-management#执行计划绑定-sql-binding

1 个赞

不知道的话,先从pd的dashboard 查一天的慢SQL, 按内存排序看一下前几条慢SQL 看是否能优化一下。

1 个赞

知道是那个sql,但是不知道怎么处理

1 个赞

以上SQL可否先过滤数据,再进行union操作。
看执行计划,除全表扫描外,其他环节涉及的数据量并不大。可否提前让A表与amazon_stock_age表关联进行数据过滤,再进行group by,然后再对结果集进行union。

1 个赞

我跟写sql的提提,现在最主要想解决跑这类查询数据量大的情况不宕机,有啥办法限制吗,我设置了单条SQL最多使用的内存但是不生效, 内存还是持续上涨

1 个赞

从执行节点来看,你的sql并未有效利用tikv节点,建议优化sql使算子下推到tikv节点。

1 个赞

感谢指点

其实任何数据库都不喜欢太复杂的。
很多要在设计层面解决。

该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。