【 使用环境 】测试环境
【 OB or 其他组件 】oceanbase 4.3.5.3
【 使用版本 】4.3.5.3
【问题描述】
1、我们发现，我有个SQL，经常引起重启。
这个SQL类似于之前提到过的一个case：
业务从MySQL迁移至Oceanbase过程中，发现部分SQL查询不出结果 - 社区问答- OceanBase社区-分布式数据库
问题的SQL部分类似如下格式：
2、因为开发并不会那么了解oceanbase，不是特别清楚这个缺陷。有时都会按照他们的习惯来。
但是，这个引出了另外一个问题：
我们可以看到，有的SQL会引起内存在极短时间激增，这就很难办了。
我们可以看到，内存方面的增长速度是非常快的，而且这个现象，对我们这样的老系统比较容易出现。
3、我们自己定位问题的过程中：
如何定位可能导致租户内存跑满的 SQL-OceanBase数据库使用指南
我们在想这类问题是否比较难避免呢？
observer上也发现很多“use too much memory”
请问我们这种场景下能怎么样让oceanbase稳定一些呢？
另外，下面这个问题能否让oceanbase的优化器自主地判断出 /*+ PUSH_SUBQ */的场景，不熟悉的童鞋，确实蛮容易出现这个问题。
业务从MySQL迁移至Oceanbase过程中，发现部分SQL查询不出结果 - 社区问答- OceanBase社区-分布式数据库
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
论坛小助手
#3
您好，您提的这个技术问题可能牵涉到 OceanBase 企业版范围内的功能细节；针对此类问题，建议你通过以下方式寻求帮助：
-
如你所在的企业客户已签署 OceanBase 企业版销售合同，请你联系客户经理；
-
如你所在的企业客户尚未签署 OceanBase 企业版销售合同，你可通过OceanBase官网商务咨询页面留下你的联系方式，OceanBase企业版的业务顾问会在一个工作日内与你联系。
另外，我们欢迎你使用社区版，并在论坛/社群中分享你对社区版本的想法、经验和问题，与其他社区成员共同交流。
(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)
淇铭
#4
你这个ob是企业版么？SHOW VARIABLES like ‘version_comment’; 查一下 版本号
你加了这个hint以后 /*+ PUSH_SUBQ */ 还会有问题么
查一下gv$ob_sql_audit信息
使用obdiag收集一下出现问题前后十分钟的日志
obdiag gather log [options]
https://www.oceanbase.com/docs/common-obdiag-cn-1000000003607759
旭辉
#5
1、这次提及的问题主要 是针对社区版本的，我们测试这边还是以社区版本为主。商业版提及后就加补丁修复，可以请求研发团队把这个小问题更新到社区版吗？
社区版本：
2、这个hint能解决问题，但是，问题是，开发不是特别熟悉，容易触发~~~
3、observer宕机重启后过了一段时间，我晚点收集一下obdiag gather log的内容哈~
非常非常感谢老师了~~~
query_memory_limit_percentage 的配置我们也尝试一下。主要是，有时内存激增得太快~
老师，我们已经降低query_memory_limit_percentage，感觉很有用，我们再正常运行一下，
另外，我想咨询一下，原本这个服务器的可用内存还有 19G，跑了一些占用内存的SQL，原本变成2.2G手动关闭了，现在变成3.5G了。
请问老师，可以怎么样快速地恢复可用的内存呢。
淇铭
#9
如果商业版修复了这个问题 后期社区版也会更新修复的 目前绕过去的办法是/*+ PUSH_SUBQ */ PUSH_SUBQ 用于指示优化器尽早执行未改写成连接的子查询 目前还是这个缺陷造成的问题
旭辉
#10
memory_limit 或者 memory_limit_percentage 设置的是多少？
老师，您好，目前配置为： memory_limit_percentage=90；
因为是 64G的服务器，觉得给了90%，还有10G呢。
我试着结合老师说的，query_memory_limit_percentage测试一下。
我估摸是否应该调整为：
memory_limit_percentage = 80；
query_memory_limit_percentage = 10；
目前服务器的内存在缓慢地恢复。现在有4G了。
当然，本质上还是我们这边的SQL问题，导致所有可用内存都被瞬间打满，我们又强调了一下尽量不要用join on id = (select id from xxx)
主要是我们这老系统，这些坑坑洼洼的事情不少~ 
就是有时，那个，等待的时间稍微稍微似乎有点点熬人。
冒昧问问，能否方便，帮我们咨询一下估摸哪个版本有机会优化一下这个问题呢？ 
好的好的，谢谢啦，其实我们是希望你们的产品越来越好的。
老师，似乎这个参数，没太大效果。
测试相同语句，还是将主节点的observer整宕机了。
我们已经将默认参数调整为：query_memory_limit_percentage = 10
memory_limit_percentage = 80
