StarRocks ANALYZE PROFILE 详解基于 Query Profile 的树形执行分析【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocksANALYZE PROFILE 是 StarRocksv3.1 起提供的一条专用 SQL 语句用于以 Fragment执行片段为单位、以树形结构分析指定查询的 Query Profile帮助开发者从执行计划层面快速定位慢查询瓶颈。本文将完整讲解该语句的语法、参数、输出结构、底层实现原理并结合仓库源码与配套语句SHOW PROFILELIST、EXPLAIN ANALYZE给出可复用的调优工作流。功能概述Query Profile 记录了查询执行过程中所有工作节点的执行信息是 StarRocks 诊断与调优查询性能的强有力工具。而 Query Profile 概述 中介绍的各种 Profile 获取方式Web UI、get_query_profile()函数等返回的都是原始文本人工阅读成本较高。ANALYZE PROFILE 则对指定查询的 Profile 做结构化再加工以Fragment 为单位组织展示每个 Fragment 下的计划节点Plan Node及其指标被整理成树形结构符合执行计划本身的层级关系支持按需下钻指定plan_node_id后可查看该节点的详细指标并对使用占比较高的指标做高亮便于快速定位热点对已结束或正在运行的查询均可分析只要该查询的 Profile 仍缓存在 FE 内存中就可以用query_id随时回溯。需要说明的是ANALYZE PROFILE 本身不执行任何 SQL它只读取已存在的 Profile 快照并格式化输出因此成本极低适合作为慢查询复盘的标准动作。权限要求注意只有对特定表拥有SELECT 权限的用户才能执行此操作。该限制与SHOW PROFILELIST无需权限不同与EXPLAIN ANALYZE需要 SELECT 或 INSERT 权限相近。从权限设计可以推断ANALYZE PROFILE 的 Profile 内容可能涉及表的执行细节扫描行数、谓词、分区裁剪等因此 StarRocks 将其视为对表数据的间接访问要求最小化权限授权。语法与参数语法ANALYZE PROFILE FROM query_id, [plan_node_id[, ...] ]参数说明参数说明query_id查询 ID。可以通过 SHOW PROFILELIST 获得。plan_node_idQuery Profile 中的计划节点 ID。指定后可查看对应计划节点的详细指标若不指定则仅显示所有计划节点的摘要指标。参数细节说明query_id是字符串语法上需要用单引号包裹例如ANALYZE PROFILE FROM a40456b2-8428-11ee-8d02-6a32f8c68848plan_node_id是整数多个节点 ID 用逗号分隔例如ANALYZE PROFILE FROM query_id, 0, 1, 2若要查看整棵执行计划树的详细指标可依次对每个 Fragment 下的关键节点执行 ANALYZE PROFILE。从 StarRocks.g4 的语法定义看该语句还额外支持LAST_QUERY_ID()简写形式analyzeProfileStatement : ANALYZE PROFILE FROM string | ANALYZE PROFILE FROM string , INTEGER_VALUE (, INTEGER_VALUE)* | ANALYZE PROFILE FROM LAST_QUERY_ID ( ) | ANALYZE PROFILE FROM LAST_QUERY_ID ( ) , INTEGER_VALUE (, INTEGER_VALUE)*即-- 直接分析当前会话最近一次查询的 Profile ANALYZE PROFILE FROM LAST_QUERY_ID(); -- 分析最近一次查询中节点 0、1 的详细指标 ANALYZE PROFILE FROM LAST_QUERY_ID(), 0, 1;AnalyzeProfileParserTest.java 中的用例如ANALYZE PROFILE FROM test-query-id, 1, 2, 3、ANALYZE PROFILE FROM LAST_QUERY_ID(), 0, 1印证了上述两种语法的解析路径。输出结构详解ANALYZE PROFILE 的输出由 ExplainAnalyzer.analyze() 生成由两个主要部分构成Summary概要概要部分包含以下信息QueryID查询 ID与SHOW PROFILELIST中展示的 ID 一致版本信息产生该 Profile 的 StarRocks 版本查询状态Finished、Error、Running三种之一总查询耗时内存使用情况CPU 使用率最高的 Top 10 节点内存使用最高的 Top 10 节点与会话默认值不同的 Session 变量这部分在排查为什么这个查询这么慢时非常有用例如pipeline_dop、parallel_fragment_exec_instance_num等被修改过的变量会在这里列出。Fragments各 Fragment 指标展示每个 Fragment 中各节点的时间、内存使用、代价估算信息与输出行数时间占比超过 30% 的节点会以红色高亮时间占比超过 15% 且低于 30% 的节点会以粉色高亮。高亮机制是本功能的核心价值无需逐行比对指标热点节点在视觉上一目了然。在 Query Profile 文本化分析 中对此有更详细的说明。指定节点 ID 时的输出差异不指定plan_node_id只展示各节点的摘要指标时间、内存、输出行数等用于快速定位哪个节点最慢指定plan_node_id输出该节点对应的全部详细指标输入输出行数、CPU 时间、内存、各类执行时间细分等并高亮使用占比较高的指标用于深入分析这个节点为什么慢。底层实现原理从 FE 源码可以还原 ANALYZE PROFILE 的完整调用链语法解析AstBuilder根据 StarRocks.g4 将语句构建为 AnalyzeProfileStmt其中保存queryId与planNodeIds两个字段执行入口StmtExecutor判断parsedStmt instanceof AnalyzeProfileStmt后进入handleAnalyzeProfileStmt()Profile 查找通过ProfileManager.getInstance().getProfileElement(queryId)从 FE 内存中取出缓存的 Profile若找不到会抛出异常Query profile not found for query_id: ... The query may have been evicted from memory.——这意味着 Profile 的保留时间有限建议在查询结束后尽早分析格式转换调用ExplainAnalyzer.analyze(profileElement.plan, profileElement.getRuntimeProfile(), planNodeIds, ...)将 RuntimeProfile 结合执行计划plan渲染成带高亮的树形文本。边界情况短路径查询Short Circuit源码中对ProfileElement#plan null且查询类型非 Load 的情况会直接报错提示可用SET enable_short_circuit false关闭短路径后再分析。这说明短路径点查如主键点查不生成完整执行计划无法用 ANALYZE PROFILE 分析Profile 已失效如果 Profile 被移出内存例如查询时间久远语句会报错需要重新执行查询并尽快分析。获取 query_id 的配套语句SHOW PROFILELIST执行 ANALYZE PROFILE 前需要先通过 SHOW PROFILELIST 获取目标查询的 IDSHOW PROFILELIST [LIMIT n];其中LIMIT n用于列出最近 n 条记录。返回字段如下返回列说明QueryId查询 ID供 ANALYZE PROFILE 使用。StartTime查询开始时间。Time查询延迟。State查询状态Error出错、Finished完成、Running运行中。Statement查询语句内容。示例SHOW PROFILELIST LIMIT 5;输出形如----------------------------------------------------------------------------------------------------------------- | QueryId | StartTime | Time | State | Statement | ----------------------------------------------------------------------------------------------------------------- | a40456b2-8428-11ee-8d02-6a32f8c68848 | 2023-11-16 10:34:18 | 21ms | Finished | SELECT ROUTINE_NAME FROM ... | | a26ec286-8428-11ee-8d02-6a32f8c68848 | 2023-11-16 10:34:15 | 269ms | Error | EXPLAIN ANALYZE SELECT c_nation ... | -----------------------------------------------------------------------------------------------------------------该语句无需任何权限且能列出运行中超过 10 秒的查询——这意味着你可以对慢到还没结束的查询直接分析其 Runtime Query Profile。last_query_id() 与 get_query_profile()last_query_id()返回当前会话最近一次执行的查询 ID配合ANALYZE PROFILE FROM LAST_QUERY_ID()可省去手动复制 ID 的步骤get_query_profile(query_id)以 SQL 函数形式返回指定查询的原始文本 Profile适合脚本化抓取。完整工作流示例参考 Query Profile 概述SET enable_profile true; -- 执行一个包含扫描与聚合的查询以产生有意义的 Profile SELECT count(*) FROM information_schema.columns; -- 获取该查询的 query_id SELECT last_query_id(); -------------------------------------- | last_query_id() | -------------------------------------- | 019b364f-10c4-704c-b79a-af2cc3a77b89 | -------------------------------------- -- 查看 Profile 列表 SHOW PROFILELIST; -- 结构化分析 Profile树形展示 ANALYZE PROFILE FROM 019b364f-10c4-704c-b79a-af2cc3a77b89; -- 下钻到节点 0 的详细指标 ANALYZE PROFILE FROM 019b364f-10c4-704c-b79a-af2cc3a77b89, 0;使用示例示例一不指定节点 ID查看整棵执行树的摘要。输出按 Fragment 组织每个节点展示时间、内存、输出行数等摘要指标时间占比超过 30% 的节点以红色高亮、15%30% 的以粉色高亮热点一目了然。示例二指定节点 ID 为 0查看该节点的全部详细指标。StarRocks 返回 Node ID 为0的所有详细指标并高亮使用占比较高的指标便于定位该节点内部的瓶颈。使用建议先摘要后下钻先执行不带plan_node_id的语句确定热点节点再针对热点节点指定 ID 查看细节避免信息过载关注 Summary 的会话变量差异被修改过的 Session 变量往往是非预期慢的元凶分析运行中的查询当查询卡住超过 10 秒时可先用SHOW PROFILELIST找到Running状态的查询再对其执行 ANALYZE PROFILE此时输出中会包含算子状态⏳ 未开始、 运行中、✅ 已完成与整体/算子级进度信息注意客户端兼容性输出文本包含 ANSI 颜色字符推荐使用 MyCLI 客户端使用不支持 ANSI 的客户端如部分 MySQL 客户端可能出现轻微排版错乱通常不影响阅读。与 EXPLAIN ANALYZE 的分工EXPLAIN ANALYZE 与 ANALYZE PROFILE 是互补的两条语句维度ANALYZE PROFILEEXPLAIN ANALYZE是否执行 SQL否仅分析已有 Profile是执行并生成新 Profile适用对象历史/运行中的任意查询含他人发起的当前会话将要执行的 SELECT / INSERT INTO 语句权限要求目标表的 SELECT 权限目标表的 SELECT 或 INSERT 权限典型场景慢查询复盘、生产问题回溯上线前模拟验证、对比改写前后的执行效果EXPLAIN ANALYZE 的语法EXPLAIN ANALYZE statement;注意两点使用限制支持 SELECT 与 INSERT INTO 两类语句但INSERT INTO 的 Profile 分析仅支持默认 Catalog 下的内表且分析过程中不会真正写入数据——导入事务默认会被中止确保分析过程不产生数据变更执行EXPLAIN ANALYZE时StarRocks 会默认在当前会话开启 Query Profile 功能。前置条件确保 Profile 可用ANALYZE PROFILE 依赖 FE 内存中缓存的 Profile因此分析前需确保对应查询已生成 Profile开启 ProfileSET enable_profile true; -- 仅当前会话 SET GLOBAL enable_profile true; -- 全局生效生产环境不建议长期开启只捕获慢查询推荐的生产姿势设置big_query_profile_threshold只对超过阈值的查询生成 Profile避免全局开启带来的额外开销SET global big_query_profile_threshold 30s; -- 30 秒 SET global big_query_profile_threshold 500ms; -- 500 毫秒 SET global big_query_profile_threshold 60m; -- 60 分钟及时分析Profile 在 FE 内存中缓存被淘汰后将无法用 ANALYZE PROFILE 回溯请在查询结束后尽快执行。相关文档SHOW PROFILELIST获取查询 ID 列表EXPLAIN ANALYZE模拟执行并分析新查询的 ProfileQuery Profile 概述Profile 的开启、获取与整体解读Query Profile 文本化分析ANALYZE PROFILE 输出结构的深度解读Query Profile 算子指标各算子的指标含义总结ANALYZE PROFILE 是 StarRocks 查询调优链路中连接Profile 采集与瓶颈定位的关键一环通过SHOW PROFILELIST拿到query_id用ANALYZE PROFILE以 Fragment 为单位的树形结构快速锁定热点节点再配合plan_node_id下钻与EXPLAIN ANALYZE验证优化效果即可形成定位 → 下钻 → 验证的完整闭环。其输出中的红色/粉色高亮、Summary 会话变量差异、以及运行中查询的进度展示都极大降低了慢查询分析的门槛是从 v3.1 起每个 StarRocks 开发者都应掌握的基础调优手段。【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考