StarRocks `inspect_related_mv` 函数详解：一条 SQL 查询表的全部物化视图依赖

StarRocksinspect_related_mv函数详解一条 SQL 查询表的全部物化视图依赖【免费下载链接】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/starrocksinspect_related_mv是 StarRocks 提供的一组 Meta Functions元数据检查函数之一用于在 SQL 会话中直接查看「哪些异步物化视图引用了某张表/视图」并以 JSON 数组形式返回结果。本文基于官方文档与 FE 侧源码实现讲解该函数的语法、返回结构、递归依赖语义、权限要求与底层实现原理帮助你快速排查物化视图血缘关系、定位基表变更影响范围。函数概述inspect_related_mv是一个 FE 侧实现的常量元函数meta function调用时传入表名返回该表直接及间接关联的所有物化视图信息返回格式为 JSON 数组的 VARCHAR 字符串。inspect_related_mv(table_name)该函数与inspect_mv_meta、inspect_mv_plan、inspect_mv_relationships、inspect_mv_refresh_info等同属于 StarRocks 的元数据检查函数族见 docs/en/sql-reference/sql-functions/meta-functions 目录这类函数的主要用途正如其源码注释所描述Meta functions can be used to inspect the content of in-memory structures, for debug purpose见 MetaFunctions.java即排查 FE 内存中的元数据状态属于调试与运维辅助工具。参数说明参数类型说明table_nameVARCHAR待检查的表名。可以是普通基表、视图或物化视图自身支持db.table形式完整限定名也支持跨 catalog 的catalog.db.table形式从源码看table_name会被解析为TableName对象TableName.fromString随后通过GlobalStateMgr.getCurrentState().getMetadataMgr().getTable(new ConnectContext(), tableName)在元数据管理器中解析为具体的Table对象见 MetaFunctions.java。因此该参数不仅支持 StarRocks 内表也支持通过 Catalog 挂载的外部表只要该表被物化视图引用即可查询到依赖关系。返回值返回类型为 VARCHAR内容是一个 JSON 数组数组中的每个元素对应一个直接或间接引用该表的物化视图其结构如下JSON 字段类型说明idlong物化视图在 FE 元数据中的唯一 ID即MvId中的 idnamestring物化视图名称levelint依赖层级0表示直接引用传入表的物化视图1表示嵌套依赖即引用物化视图的物化视图以此类推related_mvsJSON 数组嵌套的related_mvs字段表示该物化视图自身又被哪些更上层的物化视图引用递归展开也就是说该函数的返回结果天然携带嵌套结构通过level字段与内嵌的related_mvs数组可以完整还原一张表上层层叠加的物化视图依赖链。示例示例 1查看基表的直接关联物化视图以官方文档中的示例为例查询ss表的关联物化视图mysql select inspect_related_mv(ss); --------------------------------------------------------------------- | inspect_related_mv(ss) | --------------------------------------------------------------------- | [{id:28806,name:mv_on_view_1},{id:28844,name:test_mv1}] | --------------------------------------------------------------------- 1 row in set (0.01 sec)输出结果是一个 JSON 数组包含两个物化视图mv_on_view_1id 28806与test_mv1id 28844。由于它们都直接引用ss表因此level均为0示例中为简洁起见未展开嵌套数组。示例 2指定库名查询当表不在当前默认数据库时可以使用db.table完整限定名mysql select inspect_related_mv(tpch.ss); --------------------------------------------------------------------- | inspect_related_mv(tpch.ss) | --------------------------------------------------------------------- | [{id:28806,name:mv_on_view_1,level:0,related_mvs:[]}, | | {id:28844,name:test_mv1,level:0,related_mvs:[]}] | ---------------------------------------------------------------------示例 3查看多级嵌套依赖假设在test_mv1之上又创建了物化视图mv_on_mv1则查询ss表时会返回嵌套结构mysql select inspect_related_mv(ss); ----------------------------------------------------------------------------------------------------- | inspect_related_mv(ss) | ----------------------------------------------------------------------------------------------------- | [{id:28806,name:mv_on_view_1,level:0,related_mvs:[]}, | | {id:28844,name:test_mv1,level:0,related_mvs: | | [{id:28890,name:mv_on_mv1,level:1,related_mvs:[]}]}] | -----------------------------------------------------------------------------------------------------其中test_mv1的level为0而它的嵌套related_mvs中mv_on_mv1的level为1清楚展示了「表 → 物化视图 → 物化视图」的多级血缘关系。底层实现原理inspect_related_mv的实现位于 FE 的优化器常量函数注册表中核心代码见 MetaFunctions.javaConstantFunction(name inspect_related_mv, argTypes {VARCHAR}, returnType VARCHAR, isMetaFunction true) public static ConstantOperator inspectRelatedMv(ConstantOperator name) { TableName tableName TableName.fromString(name.getVarchar()); Table table inspectExternalTable(tableName); JsonArray array new JsonArray(); SetMvId visited Sets.newHashSet(); ... collectRelatedMvsRecursively(dbId, table, array, 0, visited); String json array.toString(); return ConstantOperator.createVarchar(json); }关键实现要点如下函数注册方式通过ConstantFunction注解注册argTypes {VARCHAR}、returnType VARCHAR并标记isMetaFunction true。这意味着它在查询计划阶段就会被常量折叠为字符串字面量不会下发到 BE 执行。权限校验表解析使用inspectExternalTable其中调用Authorizer.checkAnyActionOnTable校验当前用户对目标表具备任意操作权限否则抛出AccessDeniedException见 MetaFunctions.java。递归收集核心逻辑在collectRelatedMvsRecursively中。它通过table.getRelatedMaterializedViews()获取直接引用该表的物化视图 ID 集合SetMvId随后对每个MvId解析出对应的库与物化视图对象为其生成 JSON 对象id、name、level并继续递归收集该物化视图自身的下游依赖填入嵌套的related_mvs数组层级level随之递增见 MetaFunctions.java。环路防护使用SetMvId visited记录已访问的物化视图避免依赖环或重复引用导致无限递归。并发安全读取每个表的关联物化视图时通过Locker.lockTableWithIntensiveDbLock(dbId, table.getId(), LockType.READ)加读锁保护读取完成后在finally中释放保证与 DDL 等写操作并发时的元数据一致性。MvId结构MvId封装了物化视图的dbId与id源码见 MvId.java函数利用getDbId()/getId()在全局元数据GlobalStateMgr.getCurrentState().getLocalMetastore()中定位物化视图对象。测试用例佐证FE 侧的单元测试覆盖了该函数的基本行为见 ConstantExpressionTest.java// inspect_related_mv testFragmentPlanContains(select inspect_related_mv(mv_base_table_9527), name\:\mv1\);该用例先创建了基表mv_base_table_9527与物化视图mv1然后断言执行计划中包含name:mv1的输出片段验证了函数返回的 JSON 中确实携带物化视图名称。使用场景与注意事项典型使用场景变更影响分析对基表执行 DDL如加列、改类型或删除前先调用该函数确认哪些物化视图会受影响避免破坏物化视图的刷新与改写。血缘排查配合inspect_mv_plan查看物化视图逻辑计划与inspect_mv_relationships查看 ConnectorTblMetaInfoMgr 中基表到物化视图的映射关系见 MetaFunctions.java共同使用可完整还原物化视图的构建与依赖关系。多级依赖梳理通过返回结果中的嵌套related_mvs与level字段一眼看出物化视图链上的每一层判断是否存在过深的嵌套刷新链路。注意事项该函数是 FE 内存元数据的实时快照返回结果会随物化视图的创建、删除实时变化。调用需要对目标表拥有任意权限SELECT等无权限时将返回访问被拒绝的错误。table_name建议使用完整限定名catalog.db.table或db.table避免因当前默认库不同而解析到错误的表。返回值为 JSON 字符串若需要二次处理可在外层使用 JSON 函数如parse_json、json_query等继续解析。小结inspect_related_mv以一行 SQL 的形式为 StarRocks 异步物化视图的运维诊断提供了直观的依赖查询入口。其递归返回的嵌套 JSON 结构id、name、level、related_mvs可以完整刻画从基表到多级物化视图的血缘拓扑配合源码中基于MvId元数据遍历与读锁保护的实现可以安全地在生产环境排查物化视图依赖关系。如果需要更深层的诊断可进一步阅读同目录下的 inspect_mv_meta.md、inspect_mv_plan.md 与 inspect_mv_relationships.md 等文档。【免费下载链接】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），仅供参考