sql查询不稳定，时快时慢，绑定执行计划之后还是会出现这种情况，分析原因

zaochun · 2025 年12 月 5 日 16:30

【使用环境】生产环境 or 测试环境
【 OB or 其他组件】
【使用版本】observer-4.3.5.4
【问题描述】清晰明确描述问题
OCP提示存在慢sql：

表结构如下：
CREATE TABLE deal_order_real_name_pdf (
ORDER_ID varchar(80) COLLATE utf8mb4_bin DEFAULT NULL COMMENT ‘订单号’,
CREATE_TIME datetime(6) DEFAULT CURRENT_TIMESTAMP(6) COMMENT ‘创建时间’,
PDF_URL varchar(500) COLLATE utf8mb4_bin DEFAULT NULL COMMENT ‘协议pdf文件地址’,
EXT_SYSTEM varchar(100) COLLATE utf8mb4_bin DEFAULT NULL COMMENT ‘外系统编码’,
FILE_DATE varchar(80) COLLATE utf8mb4_bin DEFAULT NULL COMMENT ‘文件日期’,
FILE_TIME varchar(100) COLLATE utf8mb4_bin DEFAULT NULL COMMENT ‘文件修改时间’,
PDF_SOURCE varchar(10) COLLATE utf8mb4_bin DEFAULT ‘1’ COMMENT ‘s_dic type=’‘NEW_REAL_NAME_PDF_SOURCE’’:1.同步it服务器上的pdf文件;2.后台生产人员上传的pdf文件’,
HAS_JPG varchar(10) COLLATE utf8mb4_bin DEFAULT ‘0’ COMMENT ‘0无图片 1.有图片’,
HAS_ARCHIVE varchar(10) COLLATE utf8mb4_bin DEFAULT ‘0’ COMMENT ‘0.未归档 1.已归档’,
ARCHIVE_FILE varchar(500) COLLATE utf8mb4_bin DEFAULT NULL COMMENT ‘归档文件名’,
PATH_MOUNT varchar(200) COLLATE utf8mb4_bin DEFAULT NULL COMMENT ‘文件服务器绝对地址’,
UNIQUE KEY REAL_NAME_PDF_ORDER_ID (ORDER_ID) BLOCK_SIZE 16384 LOCAL,
KEY IX_DEAL_ORDER_REAL_NAME_PDF2 (CREATE_TIME, PDF_SOURCE, FILE_DATE) BLOCK_SIZE 16384 LOCAL,
KEY IX_DEAL_ORDER_REAL_NAME_PDF1 (PDF_SOURCE, FILE_DATE) BLOCK_SIZE 16384 LOCAL,
KEY REAL_NAME_PDF_CREATE_TIME (CREATE_TIME) BLOCK_SIZE 16384 LOCAL,
KEY REAL_NAME_PDF_FILE_DATE (FILE_DATE) BLOCK_SIZE 16384 LOCAL
) ORGANIZATION INDEX DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_bin ROW_FORMAT = DYNAMIC COMPRESSION = ‘zstd_1.3.8’ REPLICA_NUM = 3 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE ENABLE_MACRO_BLOCK_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0
表的总行数是1.1亿，其中符合PDF_SOURCE = '1’的数据是107132216；
select count(distinct(PDF_SOURCE)),count(*) from DEAL_ORDER_REAL_NAME_PDF；
7 ， 110773094
绑定执行计划如下：

本地多次测试发现根据部分条件查询到的结果存在跳变（直连observer节点多次查询，该节点是表的leader节点）：

多次执行explain select CREATE_TIME from DEAL_ORDER_REAL_NAME_PDF where CREATE_TIME > NOW() - 7 and PDF_SOURCE = ‘1’; 发现 NOW() - 7 的过滤范围变成‘0000-00-00 00:00:00.000000’

问题描述：
发生上面这种情况的原因是什么？

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

论坛小助手 · 2025 年12 月 5 日 16:36

根据您的描述，SQL 查询出现不稳定，时快时慢的情况，即使绑定了执行计划，仍然存在这个问题。OCP 提示存在慢 SQL。针对这个问题，我们可以先从 SQL 性能问题的角度入手，通过 obdiag 工具来采集相关信息并进行根因分析。

推荐使用 obdiag 工具进行根因分析和日志采集，并且将采集到的日志提供给我们以便确认问题所在。
根因分析场景: SQL性能问题
根因分析命令: obdiag rca run --scene=sql_performance
日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

请替换上述命令中的 IP 地址、端口、用户名、密码、数据库名以及 trace_id（如果您有的话）为您实际情况。运行完上述命令后，您可以将生成的日志文件提供给我们，我们将根据日志进一步分析问题原因。

另外，为了确定具体的问题，在此需要您提供一些信息：

慢 SQL 的具体查询语句是什么？
您是否可以提供一个具体的 trace_id，以便我们更准确地定位问题？
是否有最近的系统变更或操作可能影响了 SQL 的性能？
表的数据量是多少？是否存在大量的数据倾斜？
服务器资源（如 CPU、内存、I/O）的使用情况如何？

谢谢！希望以上信息对您有所帮助。如果有任何疑问，欢迎随时联系我们。

附上敏捷诊断工具 obdiag 使用帮助链接

zaochun · 2025 年12 月 5 日 17:14

1.慢sql：SELECT MAX(T.FILE_DATE) V_MAX_DATE FROM DEAL_ORDER_REAL_NAME_PDF T WHERE T.PDF_SOURCE = ‘1’ AND T.CREATE_TIME > NOW() - 7;

2.trace_id如下：

3.没有系统变更和操作
4.单表，数据量1.1亿行，不存在数据倾斜
5.服务器资源平稳

obdiag 日志分析无法提供，稍后提供一下observer日志文件

淇铭 · 2025 年12 月 5 日 17:15

deal_order_real_name_pdf这个表的数据提供几条
SHOW VARIABLES like ‘version_comment’;
使用obdiag收集一下这两次不一样的信息
– 方法一：通过sql_audit中获取trace_id
select query_sql,trace_id from oceanbase.GV$OB_SQL_AUDIT where query_sql like ‘xxx%’ order by REQUEST_TIME desc limit 5;
obdiag gather plan_monitor --trace_id YB420BA2D99B-0005EBBFC45D5A00-0-0 --env “{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’}”
https://www.oceanbase.com/docs/common-obdiag-cn-1000000004494424

zaochun · 2025 年12 月 5 日 17:24

2.下面这两个trace_id的obdiag gather plan_monitor可以吗

淇铭 · 2025 年12 月 5 日 17:26

应该不行主要看看如图不一样的信息如果能复现也可以取trace_id 这两个信息都是绑定outline以后执行的么？

zaochun · 2025 年12 月 5 日 17:27

[quote=“淇铭, post:6, topic:35635695”]
deal_order_real_name_pdf
obclient(root)[xx]> select * from deal_order_real_name_pdf limit 2\G
*************************** 1. row ***************************
ORDER_ID: 6900000000010xxxxx
CREATE_TIME: 2022-03-07 14:13:24.000000
PDF_URL: xxxxxffile/20xxxx7/xx/xxxxxxx00083.pdf
EXT_SYSTEM: 1xx00xx3
FILE_DATE: 20220307
FILE_TIME: NULL
PDF_SOURCE: 1
HAS_JPG: 1
HAS_ARCHIVE: 0
ARCHIVE_FILE: NULL
PATH_MOUNT: /xxh/axxxxxt_new
*************************** 2. row ***************************
ORDER_ID: xxxxxxxxx2475087
CREATE_TIME: 2022-03-07 14:13:26.000000
PDF_URL: xxxxxfile/xxxx/xx/xxxxxxxxx083.pdf
EXT_SYSTEM: 10xxxxxxx
FILE_DATE: 20220307
FILE_TIME: NULL
PDF_SOURCE: 1
HAS_JPG: 1
HAS_ARCHIVE: 0
ARCHIVE_FILE: NULL
PATH_MOUNT: /xxxa/xxxxxx_new
2 rows in set (0.015 sec)

zaochun · 2025 年12 月 5 日 17:28

都是绑定outline之后执行的，稍等我按照方法一取一下信息

zaochun · 2025 年12 月 5 日 17:35

这个查不到信息

淇铭 · 2025 年12 月 5 日 17:43

看你对比是这个语句呀不一样先收集一下这个或者你看看能不能复现复现了收集一下

应该sql_audit的信息被清理了这个语句可以直接执行收集一下就可以

你直接在ocp上看一下原先没有绑定outline的计划是不是没有走索引截个图

淇铭 · 2025 年12 月 5 日 17:46

目前看着你这个问题应该有两个
1、SELECT MAX(T.FILE_DATE) V_MAX_DATE FROM DEAL_ORDER_REAL_NAME_PDF T WHERE T.PDF_SOURCE = ‘1’ AND T.CREATE_TIME > NOW() - 7;没有绑定之前这个语句的执行计划应该有问题
2、SELECT count(*) FROM DEAL_ORDER_REAL_NAME_PDF T WHERE T.PDF_SOURCE = ‘1’ AND T.CREATE_TIME > NOW() - 7;
多次查询发现数据不一致