odp上多次执行 根据sql_id查一下这个信息
SELECT plan_id, plan_hash, plan_status, adaptive_feedback_times, first_load_time, executions, hit_count FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT
WHERE sql_id = ‘’
ORDER BY first_load_time;
根据不通observer ip地址过滤 查一下信息
SELECT svr_ip,usec_to_time(request_time),trace_id,query_sql, request_id, is_hit_plan, get_plan_time, plan_hash,plan_id, sid, client_ip FROM oceanbase.GV$OB_SQL_AUDIT WHERE sql_id = ‘’ and svr_ip=‘192.168.80.21’ ORDER BY request_time DESC LIMIT 50;
这是物理执行计划么？按照我发的步骤执行一下 信息查一下 看看结果
是的物理执行，稍等
分布式环境多种多样，执行计划可能会突变吧
无标题.txt (3.4 KB)
第一个sql有些字段没有
改成为这个执行
SELECT plan_id, plan_hash, first_load_time, executions, hit_count FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT WHERE sql_id =‘610059D25178D94DB4D94936C4A4B297’ ORDER BY first_load_time;
多次执行 看看是否命中 你执行了一次 看着是缓存了 执行多次以后 查看信息 你的ob是哪个版本
4.2.5.3
这考虑的比较复杂了吧
1、如果是执行计划突变 按照我说的 查询信息
2、如果是计划不优 使用obdiag收集一下plan_monitor信息
obdiag gather plan_monitor --trace_id YB420BA2D99B-0005EBBFC45D5A00-0-0
–env host=xx.xx.xx.xx --env port=2881 --env user=root@test --env password=*** --env database=test
https://www.oceanbase.com/docs/common-obdiag-cn-1000000006175714
目前提供信息 不足 不知道你具体要干啥 想给你解决 没有信息 也没有办法看
收藏了
期待更多分享
这篇文章对集群之间执行相同的讲解非常到位。
关于集群之间执行相同的见解很独特，受益匪浅。
读完关于集群之间执行相同的内容，感触很多。
加油！！！！
集中式差不太多
实践出真知，感谢分享实战经验
相同 SQL、相同数据但耗时波动大，通常不是 SQL 本身的问题，常见原因有：1）请求经 ODP 路由到了不同 observer，各节点负载、缓存命中不一致；2）执行计划发生了变化，可能因统计信息更新或计划缓存失效导致选了不同计划；3）后台合并/转储在某些时刻抢占 CPU 与 IO；4）分布式执行涉及跨节点 RPC，网络抖动也会体现在耗时上。定位方法：查 GV$OB_SQL_AUDIT，对比这几次执行的 svr_ip、plan_id、queue_time、execute_time、rpc 相关等待，就能判断是路由到了不同机器、还是计划变了、还是排队等待。先用 plan_id 确认计划是否一致，再看具体卡在哪个环节。
