用 DBeaver 执行计划快速定位慢查询瓶颈【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver上个月一条跑 20 秒的订单查询最后靠 DBeaver 执行计划里一个全表扫描节点解决了。执行计划就是数据库为查询排好的执行顺序图它把先读哪张表、走不走索引、怎么连接直接画成树。下面用这条慢 SQL 从头到尾走一遍边修边讲。一这条慢 SQL 是怎么跑起来的执行计划是数据库为查询排好的执行顺序图先扫哪张表、用不用索引、表之间按什么算法连接每一步都是树形图上的一个节点。上面那条 20 秒的查询计划树里 orders 表是全表扫描order_items 跟着用嵌套循环逐行探测——慢在哪看树就清楚。二在 DBeaver 里调出执行计划的三种方式在 SQL 编辑器里选中那条语句有三种入口点工具栏上的Explain按钮对当前语句生成计划按快捷键AltX效果和按钮一致只解释、不执行生成计划时查询不会真正跑一遍对着生产库也安全。EXPLAIN 与 EXPLAIN ANALYZE 的差别一句话前者只返回优化器的估算计划后者会真的执行一遍并回填实际行数与耗时数字更准但会真跑。DBeaver 把 EXPLAIN 结果渲染成树形视图的流程在编辑器源码里SQLEditor.java 中可以找到 explainPlanFromQuery 的完整链路。三看树形图先找两个危险信号拿到树形图不用逐行读先看两处。视图的渲染逻辑在 ExplainPlanViewer.java 里。信号一 全表扫描。扫描节点显示 Table Scan、没有 Index 名称或 rows 估算接近表的总行数就是全表扫描。这条慢查询的 orders 节点扫了 100 万行占掉总成本的大头。信号二连接不合理。看连接节点的顺序和算法小表没能驱动大表或者两侧都没有可用索引却在用 Nested Loop都是典型问题。健康计划里驱动表行数少连接方式与两边数据量匹配。看什么危险信号健康信号扫描节点全表扫描rows 接近全表行数索引扫描rows 只有几千连接节点Nested Loop两侧无索引Hash Join小表驱动大表过滤条件过滤后行数几乎没减少过滤大幅削减行数四动手加索引前后对比原查询SELECT * FROM orders o JOIN order_items oi ON o.id oi.order_id WHERE o.create_time 2023-01-01 AND o.status PAID;对着计划树的两个信号加两个索引CREATE INDEX idx_orders_ct_status ON orders(create_time, status); CREATE INDEX idx_oi_order_id ON order_items(order_id);加完索引重新在 DBeaver 里执行一次 explain对比前后耗时20 秒 → 0.3 秒 ⚡️orders 扫描全表扫描 100 万行 → 走索引只读几千行order_items 连接Nested Loop 逐行探测 → 走 order_id 索引命中注意这一步索引建完不要只看耗时重跑 explain 确认计划里真的变成了索引扫描才算修好五换个数据库计划长得不一样不同数据库返回的计划格式不同DBeaver 给主流库做了专门的解析器MySQL用 EXPLAIN 拿回 JSON 格式计划由 MySQLPlanJSON.java 解析成树能直接看到每个表的 type、rows、Extra 字段。PostgreSQL支持 EXPLAIN 与 EXPLAIN ANALYZE 的传统文本计划也支持可视化计划估算值与实际值可以分开对照。OceanBase计划以 JSON 返回由 OceanbasePlanJSON.java 单独解析。所以同一句 SQL 在不同库的计划长得不一样看树前先确认当前连的是哪个数据库。六生成失败时的排查清单语法错误先把这条 SQL 正常跑一遍跑不通的计划生成不出来权限不足EXPLAIN 需要对应权限换个有权限的账号再试数据库不支持个别引擎不支持 explain 或只支持 ANALYZE 模式查该引擎的官方文档解析失败数据库版本较新时检查 DBeaver 版本新版本的计划格式老解析器认不出。七把看计划变成习惯上线前对关键 SQL 跑一次 EXPLAIN ANALYZE把计划存档遇到慢 SQL先在树形图里定位扫描节点再处理连接加完索引重跑 explain确认计划里真的换了索引再关工单。慢查询从来不是玄学计划树上写得清清楚楚。【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 DBeaver 执行计划快速定位慢查询瓶颈
用 DBeaver 执行计划快速定位慢查询瓶颈【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver上个月一条跑 20 秒的订单查询最后靠 DBeaver 执行计划里一个全表扫描节点解决了。执行计划就是数据库为查询排好的执行顺序图它把先读哪张表、走不走索引、怎么连接直接画成树。下面用这条慢 SQL 从头到尾走一遍边修边讲。一这条慢 SQL 是怎么跑起来的执行计划是数据库为查询排好的执行顺序图先扫哪张表、用不用索引、表之间按什么算法连接每一步都是树形图上的一个节点。上面那条 20 秒的查询计划树里 orders 表是全表扫描order_items 跟着用嵌套循环逐行探测——慢在哪看树就清楚。二在 DBeaver 里调出执行计划的三种方式在 SQL 编辑器里选中那条语句有三种入口点工具栏上的Explain按钮对当前语句生成计划按快捷键AltX效果和按钮一致只解释、不执行生成计划时查询不会真正跑一遍对着生产库也安全。EXPLAIN 与 EXPLAIN ANALYZE 的差别一句话前者只返回优化器的估算计划后者会真的执行一遍并回填实际行数与耗时数字更准但会真跑。DBeaver 把 EXPLAIN 结果渲染成树形视图的流程在编辑器源码里SQLEditor.java 中可以找到 explainPlanFromQuery 的完整链路。三看树形图先找两个危险信号拿到树形图不用逐行读先看两处。视图的渲染逻辑在 ExplainPlanViewer.java 里。信号一 全表扫描。扫描节点显示 Table Scan、没有 Index 名称或 rows 估算接近表的总行数就是全表扫描。这条慢查询的 orders 节点扫了 100 万行占掉总成本的大头。信号二连接不合理。看连接节点的顺序和算法小表没能驱动大表或者两侧都没有可用索引却在用 Nested Loop都是典型问题。健康计划里驱动表行数少连接方式与两边数据量匹配。看什么危险信号健康信号扫描节点全表扫描rows 接近全表行数索引扫描rows 只有几千连接节点Nested Loop两侧无索引Hash Join小表驱动大表过滤条件过滤后行数几乎没减少过滤大幅削减行数四动手加索引前后对比原查询SELECT * FROM orders o JOIN order_items oi ON o.id oi.order_id WHERE o.create_time 2023-01-01 AND o.status PAID;对着计划树的两个信号加两个索引CREATE INDEX idx_orders_ct_status ON orders(create_time, status); CREATE INDEX idx_oi_order_id ON order_items(order_id);加完索引重新在 DBeaver 里执行一次 explain对比前后耗时20 秒 → 0.3 秒 ⚡️orders 扫描全表扫描 100 万行 → 走索引只读几千行order_items 连接Nested Loop 逐行探测 → 走 order_id 索引命中注意这一步索引建完不要只看耗时重跑 explain 确认计划里真的变成了索引扫描才算修好五换个数据库计划长得不一样不同数据库返回的计划格式不同DBeaver 给主流库做了专门的解析器MySQL用 EXPLAIN 拿回 JSON 格式计划由 MySQLPlanJSON.java 解析成树能直接看到每个表的 type、rows、Extra 字段。PostgreSQL支持 EXPLAIN 与 EXPLAIN ANALYZE 的传统文本计划也支持可视化计划估算值与实际值可以分开对照。OceanBase计划以 JSON 返回由 OceanbasePlanJSON.java 单独解析。所以同一句 SQL 在不同库的计划长得不一样看树前先确认当前连的是哪个数据库。六生成失败时的排查清单语法错误先把这条 SQL 正常跑一遍跑不通的计划生成不出来权限不足EXPLAIN 需要对应权限换个有权限的账号再试数据库不支持个别引擎不支持 explain 或只支持 ANALYZE 模式查该引擎的官方文档解析失败数据库版本较新时检查 DBeaver 版本新版本的计划格式老解析器认不出。七把看计划变成习惯上线前对关键 SQL 跑一次 EXPLAIN ANALYZE把计划存档遇到慢 SQL先在树形图里定位扫描节点再处理连接加完索引重跑 explain确认计划里真的换了索引再关工单。慢查询从来不是玄学计划树上写得清清楚楚。【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考