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

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

组件的信息都是v5.4

image747×375 10.5 KB

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

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

补充一下集群配置

image990×224 5.46 KB

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

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

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

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

业务角度好像优化不了了

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

有TiFlash hint 是啥呢？

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 ...]]) 提示优化器从指定的存储引擎来读取指定的表，目前支持的存储引擎参数有 TIKV 和 TIFLASH 。如果为表指定了别名，就只能使用表的别名作为 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-

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

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

执行计划管理 (SPM)

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

执行计划绑定 (SQL Binding)

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

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

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

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

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

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

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

image168×579 3.27 KB

感谢指点

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

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