环境：OceanBase 社区版 4.2.1（MySQL 模式），3 副本集群。
场景：一张按 user_id Hash 分区的业务表，索引正常，但在 OB 上执行一个简单的 JOIN 查询耗时 2 秒，同样的 SQL 在 MySQL 5.7 上仅需 200ms。用 obdiag 收集了现场信息，执行计划看下来没什么异常。
已排查：统计信息已收集，参数基本默认。
求助：这种“计划正常但执行慢”的情况，通常还应该从哪些维度入手排查？有没有遇到过类似性能倒挂的案例？
分区分太多了？分布式事务开销比较大
静态 Explain 只看逻辑算子，无法体现分布式 RPC、跨节点数据分发开销。优先查看GV$OB_SQL_AUDIT确认是否为分布式执行，核对 RPC 次数与网络耗时。检查两表分区键、分区数量，确认是否加入同一 TableGroup，判断能否走 Partition-wise 本地 Join。4.2.1 社区版常见坑：跨分区 NLJ 无法启用 Batch Rescan，可加 USE_HASH hint 验证。排查宏块缓存命中率、SSTable 数量、后台合并任务，排除 LSM 读放大。