昨天我们完成了兼容性改造但很多小伙伴在评论区问迁移完成后怎么判断OceanBase上的SQL跑得比MySQL快还是慢如果变慢了该怎么定位问题今天我们就来掌握OceanBase性能诊断的核心武器——执行计划分析。核心概念逻辑计划 vs 实际计划在OceanBase中查看执行计划有两种方式理解它们的区别至关重要逻辑执行计划EXPLAINSQL执行前的预估方案告诉你优化器打算怎么执行这条SQL。实际执行计划Plan CacheSQL执行后的真实记录告诉你优化器实际是怎么执行的。两者可能不一致因为逻辑计划基于统计信息估算而实际执行时数据分布可能已经发生了变化。10分钟实操从EXPLAIN看懂执行计划假设我们有一张订单表t_order现在执行一条查询EXPLAIN SELECT * FROM t_order WHERE order_no 202606300001;返回的执行计划中你需要重点关注以下几个字段字段含义怎么看OPERATOR操作算子TABLE SCAN表示全表扫描警惕TABLE GET表示主键定位高效NAME操作对象显示使用的索引名如果是表名说明走的是主表扫描EST.ROWS预估行数估算值与实际值差距过大说明统计信息过期COST预估成本数值越大表示该算子越重range_cond扫描条件显示索引的过滤条件判断是否命中索引 快速判断口诀看到TABLE SCANrange(MIN,MIN;MAX,MAX)就要警惕了这几乎等于全表扫描是性能杀手实操查看SQL的真实执行计划逻辑计划只是纸上谈兵要看到真实执行情况需要通过系统视图-- 第一步从SQL审计视图中找到目标SQL的plan_id SELECT sql_id, plan_id, elapsed_time, execute_time FROM gv$ob_sql_audit WHERE query_sql LIKE %t_order% ORDER BY request_time DESC LIMIT 1; -- 第二步根据plan_id查看实际执行计划 SELECT plan_depth, plan_line_id, operator, name, rows, cost, property FROM gv$ob_plan_cache_plan_explain WHERE tenant_id 1002 AND plan_id 6380340 AND svr_ip 192.168.1.100;⚠️ 重要提醒gv$ob_plan_cache_plan_explain视图只能在SQL实际执行的OBServer节点上查询。如果你是通过OBProxy连接的可能查不到数据需要直连OBServer。使用ODC图形化工具推荐新手如果你觉得命令行太复杂OceanBase开发者中心ODC提供了可视化的执行画像功能在ODC的SQL窗口执行你的查询语句执行完成后点击结果上方的执行画像图标你会看到一个可视化的执行计划树每个算子的耗时、I/O、行数一目了然系统还会自动标出耗时Top5的算子帮你快速定位瓶颈 生产环境慢查询排查思路当业务反馈某条SQL很慢时按照以下步骤排查定位慢SQL查询gv$ob_sql_audit视图按elapsed_time排序找到最耗时的SQL查看执行计划通过plan_id查询实际执行计划确认是否走了索引分析时间构成关注queue_time排队时间和execute_time执行时间如果queue_time占比高 → 说明系统资源紧张需要扩容如果execute_time占比高 → 说明SQL本身需要优化检查活跃会话如果SQL还在执行中尚未结束可以通过GV$OB_PROCESSLIST查看当前活跃会话今日小结今天我们掌握了OceanBase性能诊断的核心技能。通过EXPLAIN查看逻辑计划通过gv$ob_plan_cache_plan_explain查看实际计划再配合ODC的可视化执行画像你就能像医生看X光片一样一眼看穿SQL的性能瓶颈。 课后思考如果通过执行计划发现某条SQL确实走了全表扫描但你的WHERE条件字段上明明已经建了索引为什么索引没有生效提示隐式类型转换、函数运算、最左前缀原则都可能是凶手。