一条 SQL 跑了 8 秒?用 DBeaver 执行计划 3 分钟定位瓶颈

发布时间:2026/9/13 1:41:02
一条 SQL 跑了 8 秒?用 DBeaver 执行计划 3 分钟定位瓶颈 一条 SQL 跑了 8 秒用 DBeaver 执行计划 3 分钟定位瓶颈【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver一条 SQL 跑了 8 秒你第一反应是不是加索引先别急。把 DBeaver 的执行计划拉出来看一眼——它就是数据库的性能体检报告直接告诉你数据到底怎么被读出来的。这份报告怎么拿到、哪里有问题下面一次讲清。三步拿到执行计划打开 SQL 编辑器把慢查询写在里面。确认当前连的就是要排查的那个数据源选错库等于白忙。光标停在要分析的语句上按 CtrlShiftE或点工具栏的解释计划按钮。编辑器下方会多出一个执行计划标签页计划以树形结构呈现。带子节点的条目可以展开想换一条 SQL 重新解释重复第 2 步即可计划会按次数编号。读懂执行计划树盯住这 4 个信号执行计划树从上往下读每个节点是一次操作。不用逐行抠抓住下面 4 个信号就够了信号在哪看什么算有问题扫描方式每个表的叶子节点出现全表扫描且这张表数据量大行数估算各节点的 Rows 字段某节点预估行数明显偏大往往是慢的源头连接方式Join 节点小表 × 大表的嵌套循环代价容易被放大排序 / 聚合Sort、HashAggregate 类节点大数据量上现场排序通常可以靠索引绕开顺带留意 Cost 成本估算。它是数据库自己的判断不是实测时间但同一个计划里横向对比各节点的 Cost基本能看出优化器认为最贵的部分在哪。一个真实的优化从 5 秒到 0.1 秒先说优化前。一条查已支付订单的 SQL 跑了 5 秒SELECT o.order_no, o.create_time, oi.item_name FROM orders o JOIN order_items oi ON oi.order_id o.id WHERE o.create_time 2023-01-01 AND o.status PAID;把执行计划打开三个信号全亮orders 走了全表扫描一百万多行create_time、status 两个过滤条件没有可用的索引order_items 的关联也是全表扫描嵌套循环把它们逐行配对耗时被成倍放大。对着信号开药方给 orders 加复合索引 (create_time, status)给 order_items 的外键加索引再把 SELECT * 换成只取需要的列。CREATE INDEX idx_orders_ct_status ON orders(create_time, status); CREATE INDEX idx_oi_order_id ON order_items(order_id);优化后重新生成执行计划全表扫描消失orders 走复合索引先过滤再连接order_items 走索引连接行数从百万级降到几十。同样的 SQL5 秒变 0.1 秒。注意这里加的每条索引都是计划指出来的不是拍脑袋。对比 MySQL、PostgreSQL 等库的差别执行计划是数据库自己吐出来的各家格式不同DBeaver 按驱动配了专门的解析器你拿到的都是统一的树形视图。常见库的差异MySQL走 EXPLAIN FORMATJSON 拿结构化数据由 MySQLPlanJSON 解析成节点字段最全。PostgreSQL支持文本计划和 EXPLAIN ANALYZE 实测耗时两种模式对应 PostgreExecutionPlan 里的多套解析类。OceanBase计划以 JSON 返回由 OceanbasePlanJSON 单独解析节点字段和 MySQL 类似。Altibase驱动接口特殊走 AltibaseExecutionPlan 这类封装类拿计划。对你来说结论只有一条换库不用换方法但同一个计划在不同库里展示的细节多少有出入读的时候对照对应库的术语即可。翻车了怎么办解释失败的 3 个常见原因解释计划失败时DBeaver 会在编辑器状态栏提示类似 Cant explain plan for command。按下面 3 个原因排查语法本身有错。EXPLAIN 也要先解析 SQL语法错误直接报回数据库。先在普通执行里跑一遍确认 SQL 本身没问题再解释。权限不够。EXPLAIN 需要相应权限只读账号或权限受限的库可能拿不到计划。找 DBA 开通试试别先怀疑工具。数据库不支持。如果提示当前数据源不支持执行计划解释说明这个库的驱动没实现计划功能换支持 EXPLAIN 的库或关注 DBeaver 后续版本。三步排除下来绝大多数翻车都能定位到具体原因。下次遇到慢 SQL先让 DBeaver 把这份报告打出来再决定加什么索引。计划功能的解析和展示在持续迭代保持 DBeaver 更新到最新版有坑也可以直接去社区贴出来讨论。【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询