个别表查询一条数据超时问题

【 使用环境 】生产环境
【 OB or 其他组件 】
【 使用版本 】4.3.0
【问题描述】个别表 执行 select * from table_name limit 1 卡死
【复现路径】直接执行上述语句就会卡死
【附件及日志】
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

根据您的描述，您在使用 OceanBase 4.3.0 版本时遇到了个别表执行 SELECT * FROM table_name LIMIT 1 查询超时或卡死的问题。这可能是由多种因素导致的，例如锁冲突、资源竞争或其他潜在问题。

推荐您使用 obdiag 工具来进行日志采集和根因分析，以帮助定位具体原因。以下是您可以尝试的命令：

根因分析场景: SQL 执行出错
根因分析命令:

obdiag rca run --scene=observer.sql_err --env "{db_connect='-h<host> -P<port> -u<username>@<tenant> -p<password> -D<database>', trace_id='<your_trace_id>'}"

请将 <host>、<port>、<username>、<tenant>、<password> 和 <database> 替换为实际值。<your_trace_id> 是出现问题时的跟踪ID，如果您不知道这个ID，可以忽略此参数，但建议尽可能提供以帮助更准确地定位问题。

日志采集场景: SQL性能问题
日志采集命令:

obdiag gather scene run --scene=observer.perf_sql --env "{db_connect='-h<host> -P<port> -u<username>@<tenant> -p<password> -D<database>', trace_id='<your_trace_id>'}"

同样的，请替换上述命令中的占位符为您环境的实际值。

这两个命令分别用于从您的系统中收集可能与该问题相关的诊断信息，并试图通过这些信息来确定造成查询超时或卡住的根本原因。完成后，请将生成的日志文件打包并提供给我们，以便进一步分析。

此外，为了能够更准确地了解情况及早解决此问题，希望您可以提供更多相关信息：

1. 这个问题是频繁发生还是偶尔出现？
2. 是否只对特定的一些表存在这个问题？如果是的话，能否分享一下这些表的基本结构（如行数、列数等）？
3. 发生问题时，是否有其他大型操作正在进行，比如大规模的数据导入导出、复杂的查询或者是数据库维护活动？
4. 您能否提供具体的错误信息或异常堆栈追踪（如果有的话），这对于快速定位问题非常有帮助。
5. 请问是否已经启用了SQL审计功能？如果有开启，能否检查最近的审计日志看看是否有相关异常记录？

期待您的回复，我们将尽快协助解决问题。

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

哪些锁会导致select会卡死呢

SHOW VARIABLES like ‘version_comment’; 版本号查一下 看看

OceanBase_CE 4.3.1.0 (r100000032024051615-bad90e897a7f0f56b8ce5c43e186aa8f4bab03c4) (Built May 16 2024 17:21:43)

431这个版本 目前社区不在维护了 建议升级到高版本435bp 如果是bug的话 这个版本也不会发版修复了 建议是升级

升级版本这条路暂时行不通，审批流程太复杂；可否根据现有问题帮忙给点解决建议？

6666

锁，冲突，等待事件都看看

怎么会选择这么新的版本

这个原因还是比较多的

ᗜⰙᗜ

select * from table_name limit 1 这样查询卡死 带where条件查询的也是这样么? 有索引列的也是这样么?表的数据量有多少?

执行卡死的时候 看看这个表是否查执行sql的信息
select query_sql,svr_ip,TRACE_ID,client_ip,TENANT_NAME,user_name,DB_NAME,ELAPSED_TIME,RET_CODE,FROM_UNIXTIME(ROUND(REQUEST_TIME/1000/1000),’%Y-%m-%d %H:%i:%S’),query_sql from GV$OB_SQL_AUDIT WHERE REQUEST_TIME>=‘2024-04-05 14:34:00’ limit 10;
如果能查到信息 根据trace_id信息 过滤一下 看看
[root@x.x.x.x ~]$ grep “YB420BA1CC68-000615A09D4CBDA0-0-0” observer.log*

[root@x.x.x.x ~]$ grep “YB420BA1CC68-000615A09D4CBDA0-0-0” rootservice.log*

学习一下吧