一条 SQL 跑了 8 秒?用 DBeaver 执行计划 3 分钟定位瓶颈
【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver
一条 SQL 跑了 8 秒,你第一反应是不是加索引?先别急。把 DBeaver 的执行计划拉出来看一眼——它就是数据库的性能体检报告,直接告诉你数据到底怎么被读出来的。这份报告怎么拿到、哪里有问题,下面一次讲清。
三步拿到执行计划
- 打开 SQL 编辑器,把慢查询写在里面。确认当前连的就是要排查的那个数据源,选错库等于白忙。
- 光标停在要分析的语句上,按 Ctrl+Shift+E,或点工具栏的"解释计划"按钮。
- 编辑器下方会多出一个"执行计划"标签页,计划以树形结构呈现。带子节点的条目可以展开,想换一条 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 走索引,连接行数从百万级降到几十。同样的 SQL,5 秒变 0.1 秒。注意,这里加的每条索引都是计划"指"出来的,不是拍脑袋。
对比 MySQL、PostgreSQL 等库的差别
执行计划是数据库自己吐出来的,各家格式不同,DBeaver 按驱动配了专门的解析器,你拿到的都是统一的树形视图。常见库的差异:
- MySQL:走 EXPLAIN FORMAT=JSON 拿结构化数据,由 MySQLPlanJSON 解析成节点,字段最全。
- PostgreSQL:支持文本计划和 EXPLAIN ANALYZE 实测耗时两种模式,对应 PostgreExecutionPlan 里的多套解析类。
- OceanBase:计划以 JSON 返回,由 OceanbasePlanJSON 单独解析,节点字段和 MySQL 类似。
- Altibase:驱动接口特殊,走 AltibaseExecutionPlan 这类封装类拿计划。
对你来说结论只有一条:换库不用换方法,但同一个计划在不同库里展示的细节多少有出入,读的时候对照对应库的术语即可。
翻车了怎么办:解释失败的 3 个常见原因
解释计划失败时,DBeaver 会在编辑器状态栏提示类似 "Can't 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),仅供参考