从3分钟到0.3秒DBeaver执行计划实操手册【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver一条平时跑800毫秒的SQL业务上线让数据量翻倍后一跑就是3分钟。你盯着转圈的加载图标只能瞎猜是哪个索引没建上。其实数据库把所有答案都写在执行计划Execution Plan即查询执行的详细步骤蓝图里了。DBeaver执行计划功能把这份蓝图直接渲染成可视化的计划树。这篇带你一步步把它读出来、用来看病。30秒生成第一张执行计划生成执行计划的最快路径打开SQL Editor选中要分析的查询按AltX或者点工具栏的Explain Plan按钮结果区就会弹出计划树。不需要手敲EXPLAIN语句DBeaver替你向数据库发了请求并负责解析返回结果。完整操作就三步确认已打开数据库连接MySQL、PostgreSQL等均可在SQL Editor中选中要分析的那条语句按AltX结果区即显示计划树没选中文字时DBeaver会默认分析光标所在的那条语句。这个解释入口的代码在 SQLEditor.java想确认行为可以去翻。 读懂计划树5个必看节点先认脸。任何数据库的计划树拆开看基本就是下面五类节点节点类型长什么样看到它意味着什么要不要警惕ScanSeq Scan on orders、Index Scan数据怎么从表里读出来全表扫描且行数大时警惕JoinHash Join、Nested Loop多表怎么连接Nested Loop且两侧行数都大必须警惕AggregateGroup Aggregate、HashAggregate在做GROUP BY或DISTINCT输入行数太大时留意内存SortSort在做ORDER BY排序排序列没走索引时考虑加索引MaterializeMaterialize把中间结果存进内存反复用频繁出现时检查子查询是否在重复执行读法一句话从叶子节点往上读。叶子是Scan告诉你数据从哪来越往上的节点说明数据被加工到什么程度。哪里估算行数最大、成本最高就先怀疑哪里。⚡ 慢查询诊断从计划树里找病根诊断一条慢查询三步走先看行数再看Join最后看索引列。下面这条订单报表SQL就是典型翻车款SELECT o.order_id, SUM(oi.amount) FROM orders o JOIN order_items oi ON o.id oi.order_id WHERE o.create_time 2023-01-01 AND DATE(oi.update_time) 2023-06-01 GROUP BY o.order_id;① 哪个节点估算行数爆炸看每个节点上的估算行数Rows。口诀你看到某个Scan节点行数上百万就去检查它的过滤条件到底筛掉了多少数据。比如上面例子里orders走了条件之后行数只降了一点点说明过滤基本没生效。② Join是否退化成了Nested Loop你看到Join节点标着Nested Loop就检查它两个子节点各自的估算行数。外层100万行、内层每轮被探一次那就是天文数字次探测。这种组合下只要内表有合适索引优化器一般会换Hash Join。③ 索引列是否被函数包住了你看到索引列外面套了函数比如DATE(oi.update_time)就去检查该列上建的索引。说白了B-tree索引按原始值排序列被函数包了一层就对不上了只能全表扫。把条件改写成范围查询oi.update_time 2023-06-01 AND oi.update_time 2023-06-02索引立刻能上。改完两处再按一次AltXorders换成了Index Scan条件改范围后order_items也走了索引3分钟回到0.3秒。主流数据库的适配差异不同数据库拿计划的方式不一样DBeaver里的行为也有区别对比如下数据库获取方式DBeaver里的特殊行为MySQLEXPLAIN FORMATJSON专门解析JSON转成树显示估算行数和索引信息PostgreSQLEXPLAIN可带XML格式支持VERBOSE输出也能加载已保存的计划文件再展示OceanBase返回JSON格式计划用独立的JSON分析器解析成计划树Altibase反射调用驱动特定方法取计划文本拿到文本后交给内置解析器构建树各数据库的解析器代码就在各自的ext插件里MySQL的在 MySQLPlanJSON.java。想知道你当前连接走的是哪个解析器对号入座看对应插件就行。这些坑我帮你踩过了计划生成超时按AltX后转圈一分钟出不来。原因是查询本身太重优化器估算统计信息也卡住。处理办法是把查询拆成片段逐段解释或者先用LIMIT缩小数据范围再解释。权限不足状态栏报权限类错误计划显示不出来。原因是当前账号对涉及的表没有查询权限。处理办法是找DBA开只读分析账号别急着要全量权限。视图导致计划截断树停在视图那一层看不到底层表的Scan。原因是部分数据库的EXPLAIN默认不展开视图内部。处理办法是把查询改写为直接引用基表后再解释或者单独解释基表。只读账号看不到Cost节点上只有行数没有成本。原因是数据库本身只返回运行统计或当前账号读不到统计信息表。处理办法是按行数与节点类型来判断瓶颈别死磕成本数字。接下来往哪走路线一共三个阶段阶段一能看懂节点——五类节点背熟拿到任何计划树都能一句话说清它在干什么阶段二能改索引/改写SQL——看到全表扫描和Nested Loop知道加哪个索引、怎么改写条件阶段三能影响优化器——用各数据库的Hint或参数调整把执行路径引导到你想要的那条下次那条800毫秒的SQL再变成3分钟时先别慌着加索引。按AltX看计划树里到底哪变了。【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
从3分钟到0.3秒：DBeaver执行计划实操手册
从3分钟到0.3秒DBeaver执行计划实操手册【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver一条平时跑800毫秒的SQL业务上线让数据量翻倍后一跑就是3分钟。你盯着转圈的加载图标只能瞎猜是哪个索引没建上。其实数据库把所有答案都写在执行计划Execution Plan即查询执行的详细步骤蓝图里了。DBeaver执行计划功能把这份蓝图直接渲染成可视化的计划树。这篇带你一步步把它读出来、用来看病。30秒生成第一张执行计划生成执行计划的最快路径打开SQL Editor选中要分析的查询按AltX或者点工具栏的Explain Plan按钮结果区就会弹出计划树。不需要手敲EXPLAIN语句DBeaver替你向数据库发了请求并负责解析返回结果。完整操作就三步确认已打开数据库连接MySQL、PostgreSQL等均可在SQL Editor中选中要分析的那条语句按AltX结果区即显示计划树没选中文字时DBeaver会默认分析光标所在的那条语句。这个解释入口的代码在 SQLEditor.java想确认行为可以去翻。 读懂计划树5个必看节点先认脸。任何数据库的计划树拆开看基本就是下面五类节点节点类型长什么样看到它意味着什么要不要警惕ScanSeq Scan on orders、Index Scan数据怎么从表里读出来全表扫描且行数大时警惕JoinHash Join、Nested Loop多表怎么连接Nested Loop且两侧行数都大必须警惕AggregateGroup Aggregate、HashAggregate在做GROUP BY或DISTINCT输入行数太大时留意内存SortSort在做ORDER BY排序排序列没走索引时考虑加索引MaterializeMaterialize把中间结果存进内存反复用频繁出现时检查子查询是否在重复执行读法一句话从叶子节点往上读。叶子是Scan告诉你数据从哪来越往上的节点说明数据被加工到什么程度。哪里估算行数最大、成本最高就先怀疑哪里。⚡ 慢查询诊断从计划树里找病根诊断一条慢查询三步走先看行数再看Join最后看索引列。下面这条订单报表SQL就是典型翻车款SELECT o.order_id, SUM(oi.amount) FROM orders o JOIN order_items oi ON o.id oi.order_id WHERE o.create_time 2023-01-01 AND DATE(oi.update_time) 2023-06-01 GROUP BY o.order_id;① 哪个节点估算行数爆炸看每个节点上的估算行数Rows。口诀你看到某个Scan节点行数上百万就去检查它的过滤条件到底筛掉了多少数据。比如上面例子里orders走了条件之后行数只降了一点点说明过滤基本没生效。② Join是否退化成了Nested Loop你看到Join节点标着Nested Loop就检查它两个子节点各自的估算行数。外层100万行、内层每轮被探一次那就是天文数字次探测。这种组合下只要内表有合适索引优化器一般会换Hash Join。③ 索引列是否被函数包住了你看到索引列外面套了函数比如DATE(oi.update_time)就去检查该列上建的索引。说白了B-tree索引按原始值排序列被函数包了一层就对不上了只能全表扫。把条件改写成范围查询oi.update_time 2023-06-01 AND oi.update_time 2023-06-02索引立刻能上。改完两处再按一次AltXorders换成了Index Scan条件改范围后order_items也走了索引3分钟回到0.3秒。主流数据库的适配差异不同数据库拿计划的方式不一样DBeaver里的行为也有区别对比如下数据库获取方式DBeaver里的特殊行为MySQLEXPLAIN FORMATJSON专门解析JSON转成树显示估算行数和索引信息PostgreSQLEXPLAIN可带XML格式支持VERBOSE输出也能加载已保存的计划文件再展示OceanBase返回JSON格式计划用独立的JSON分析器解析成计划树Altibase反射调用驱动特定方法取计划文本拿到文本后交给内置解析器构建树各数据库的解析器代码就在各自的ext插件里MySQL的在 MySQLPlanJSON.java。想知道你当前连接走的是哪个解析器对号入座看对应插件就行。这些坑我帮你踩过了计划生成超时按AltX后转圈一分钟出不来。原因是查询本身太重优化器估算统计信息也卡住。处理办法是把查询拆成片段逐段解释或者先用LIMIT缩小数据范围再解释。权限不足状态栏报权限类错误计划显示不出来。原因是当前账号对涉及的表没有查询权限。处理办法是找DBA开只读分析账号别急着要全量权限。视图导致计划截断树停在视图那一层看不到底层表的Scan。原因是部分数据库的EXPLAIN默认不展开视图内部。处理办法是把查询改写为直接引用基表后再解释或者单独解释基表。只读账号看不到Cost节点上只有行数没有成本。原因是数据库本身只返回运行统计或当前账号读不到统计信息表。处理办法是按行数与节点类型来判断瓶颈别死磕成本数字。接下来往哪走路线一共三个阶段阶段一能看懂节点——五类节点背熟拿到任何计划树都能一句话说清它在干什么阶段二能改索引/改写SQL——看到全表扫描和Nested Loop知道加哪个索引、怎么改写条件阶段三能影响优化器——用各数据库的Hint或参数调整把执行路径引导到你想要的那条下次那条800毫秒的SQL再变成3分钟时先别慌着加索引。按AltX看计划树里到底哪变了。【免费下载链接】dbeaverFree universal database tool and SQL client项目地址: https://gitcode.com/GitHub_Trending/db/dbeaver创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
