集群整体查询速度变慢。

rocH · 2026 年3 月 14 日 10:31

【使用环境】生产环境
【 OB or 其他组件】
【使用版本】4.3.5.4
【问题描述】
集群架构1-1-1。
单机配置:

集群整体查询都变慢，不走索引。
巡检信息：
obdiag_check_report_observer_2026-03-13-17-08-37.log (126.9 KB)

observer.log抛出异常

检查时钟也无异常

网络重传率也不高

大量sql本来执行计划是很优秀的。却突然走了一条拉闸计划，还不会自己修正

rocH · 2026 年3 月 14 日 17:28

@论坛小助手

论坛小助手 · 2026 年3 月 14 日 17:35

集群整体查询速度变慢的问题分析

根据您提供的信息，集群整体查询速度变慢，并且不走索引。以下是可能的原因和建议：

1. 检查索引使用情况

SQL 优化：确保查询语句中正确使用了索引。可以通过 EXPLAIN 命令来查看执行计划，确认是否使用了预期的索引。
```
EXPLAIN SELECT * FROM your_table WHERE your_condition;
```
索引维护：定期检查和维护索引，确保索引的有效性。可以使用 ANALYZE TABLE 命令来更新统计信息。
```
ANALYZE TABLE your_table;
```

2. 检查系统资源使用情况

CPU 和内存：检查服务器的 CPU 和内存使用情况，确保没有资源瓶颈。
```
top
free -m
```
磁盘 I/O：检查磁盘 I/O 使用情况，确保没有磁盘瓶颈。
```
iostat -x 1
```

3. 检查网络状况

网络延迟：虽然您提到网络重传率不高，但仍需检查网络延迟和带宽使用情况。
```
ping -c 4 <remote_ip>
```
网络配置：确保网络配置正确，没有网络拥塞或丢包现象。

4. 检查日志和告警信息

日志分析：您已经提供了 obser.log 抛出异常的信息，需要进一步分析这些异常日志，找出具体的问题。
```
tail -f /path/to/obser.log
```
obdiag 工具：您已经使用了 obdiag 工具进行了巡检，但 obdiag 报告中的一些任务失败了。建议重新运行 obdiag 并检查详细的报告。
```
obdiag check --all
```

5. 检查系统参数

系统参数：检查和调整相关的系统参数，确保其设置合理。

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'query_cache_size';

6. 检查集群状态

集群状态：确保集群各节点的状态正常，没有节点出现故障或负载过高。
```
SHOW FULL PROCESSLIST;
```

7. 联系技术支持

技术支持：如果以上方法都无法解决问题，建议联系 OceanBase 的技术支持团队，获取更专业的帮助。

总结

集群整体查询速度变慢可能是由多种因素引起的，包括索引使用不当、系统资源不足、网络问题、日志异常等。通过上述步骤逐项排查，可以逐步定位问题并采取相应的解决措施。希望这些建议对您有所帮助。

更多信息请查看:

GV$OB_SQLSTAT

Amber_www · 2026 年3 月 15 日 09:18

这个问题涉及到CPU和obdiag的平衡，根据我的经验，适当调整your会有帮助。

独善其身 · 2026 年3 月 15 日 10:18

IO和CPU没有做好科学配置

rocH · 2026 年3 月 15 日 10:21

仔细讲讲，万分感谢。或者有没有经验贴

rocH · 2026 年3 月 15 日 10:23

大部分sql，本来执行计划是很优秀的，几十毫秒出结果。突然就蹦出个拉跨的计划，几十秒都出不来结果，然后还没法自动调整回来···

必须得手动绑定才能回归正常

内蒙古小草 · 2026 年3 月 15 日 11:14

开启新篇章！！

ljware · 2026 年3 月 15 日 11:16

同sql在不同时间段性能不一致吗？

淇铭 · 2026 年3 月 16 日 10:14

OceanBase 社区已接收您的帖子，正在跟进中。

牛马 · 2026 年3 月 16 日 10:16

开启新篇章！！

任仲禹 · 2026 年3 月 16 日 14:57

帮忙，截下图，看看【集群 - 资源管理】界面，的具体使用情况，IP可以打码，其它发全一点。
主要是想了解下 152核的CPU是如何分配的，是全部分给了业务租户么？留给 SYS 租户多少？（尽量给SYS租户 4C12G以上）。

淇铭 · 2026 年3 月 17 日 17:22

现象：集群sql计划突变，计划不优。

原因：
1、dml操作较多，还会有buffer表的问题。

2、查询中in传入参数数量不同的会生成不同的sql_Id。生成的执行计划会很多，达到plan cache上限以后，会淘汰掉执行计划。表的dml操作很多，导致的统计信息不准或者失效而算子估算有问题，走了不优的执行计划。

当前可实行解决方案：

1、相似的文本可以尝试绑定 format outline

2、dml操作多的表考虑重新收集统计信息

3、内存允许的条件下扩容plan cache

4、buffer表问题可以修改table_mode

rocH · 2026 年3 月 17 日 17:29

AntTech_ZT39FF · 2026 年3 月 27 日 14:16

短期可以通过绑定执行计划解决，长期建议租户开启spm功能，避免执行计划突变，详情见：https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003137377

租户级别：

set global optimizer_use_sql_plan_baselines = true;
set global optimizer_capture_sql_plan_baselines = true;
alter system set sql_plan_management_mode = ‘OnlineEvolve’;