【 使用环境 】生产环境 or 测试环境 生产
【 OB or 其他组件 】 ob 4.0
【 使用版本 】 ob 4.0
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
SQL: 该sql 跑的非常慢，大概10分钟没出结果
select USEC_TO_TIME(request_time),QUERY_SQL from sql_audit PARTITION(p20240809)
where QUERY_SQL like ‘%amm%’ and request_time > time_to_usec(now() - interval 14 hour) order by request_time asc
select count(*) from sql_audit PARTITION(p20240809)
数据量大概几个亿。
想资源下，有没有优化这种SQL 的可以操作的方法论
表写入很频繁吧？
把需要的几个字段加组合索引试试
从你的SQL语句来看，感觉是sql_audit这张表每天做一个分区，你要查询20240809这天的相关数据。
但你的where条件中基本没有有效的过滤条件，所以最终肯定是全扫描p20240809这个分区，而这个分区的数据量有几个亿，所以速度肯定快不了。。
尝试办法：
在你的SQL语句加上/*+ parallel(16) */ Hint吧， 应该比你原来的SQL快。
看看这个表对应的内部表，以及上面的索引，尽可能加上对应的条件。如 tenant_id=xxxx and svr_ip in ('xx.xx.xx.xx') and rquest_type in (1,2,3)
此外就是加 hint /*+ read_consistency(weak) parallel(16) */
用obdiag 巡检这表信息
obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’, trace_id=‘xx’}”
obdiag文档
https://www.oceanbase.com/docs/common-obdiag-cn-1000000001102504
show create table 看下对应的表结构？以及 explain 看下执行计划？
数据量太大的话，可以先想办法让 query 走上一个合适的索引，让这个索引帮你快速定位数据和消除排序开销。
你要的 SQL 优化方法论详见：《DBA 入门教程第七章的学习笔记》
巡检完了能获得哪些有利于解决这个问题的信息？
可以收集表结构信息、执行计划、执行计划缓存信息、参数信息、sql诊断信息等，是以html展示，更能直观查看信息。
我试试这个工具，谢谢
你收集完 发一下收集结果 我们好给你分析 看看是哪里的问题
哦哦，那还挺好的
