StarRocks information_schema.user_privileges 系统表完全解析定义、字段含义与正确用法【免费下载链接】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本篇技术指南围绕 StarRocks 的information_schema数据库中user_privileges系统视图展开说明该视图的字段定义、与 MySQL 兼容语义的差异以及它在 StarRocks 当前版本中的实际可用状态与正确用法。读者阅读后可以掌握如何查询该视图、理解各字段含义并明确在 StarRocks 中应使用哪些原生命令来获取真实的用户权限信息避免误用这一 MySQL 兼容占位视图。一、文档背景MySQL 兼容的信息架构视图information_schema信息架构是关系型数据库中用于暴露数据库元数据的一组只读系统表。StarRocks 在 FEFrontend节点中实现了一个 MySQL 兼容的information_schema数据库以便沿用 MySQL 生态中的查询习惯。在 InfoSchemaDb.java 中可以看到该数据库的元数据名被定义为public static final String DATABASE_NAME information_schema;其中的注释明确写到// Information schema used for MySQL compatible.即整个information_schema的定位是为 MySQL 兼容而实现。user_privileges正是该数据库中众多系统表之一由InfoSchemaDb构造函数中的super.registerTableUnlocked(UserPrivilegesSystemTable.create(catalogName))一行完成注册见 InfoSchemaDb.java。重要提示来自官方文档StarRocks 官方在 docs/en/sql-reference/information_schema/user_privileges.md 中明确指出This view does not apply to the available features in StarRocks.即该视图不适用于 StarRocks 当前提供的功能。它是一个用于保持 MySQL 信息架构形态兼容的占位placeholder视图。因此本文在讲解其定义的同时也会重点说明它「不可用」的具体原因以及替代方案。二、字段定义与类型从源码看真实的列结构官方文档给出了user_privileges的 4 个逻辑字段及其语义表格整理如下字段描述GRANTEE被授予权限的用户的名称。TABLE_CATALOG目录catalog的名称。该值始终为def。PRIVILEGE_TYPE被授予的权限。该值可以是任何可以在全局global级别授予的权限。IS_GRANTABLE如果用户具有GRANT OPTION权限则为YES否则为NO。输出不会将GRANT OPTION作为PRIVILEGE_TYPEGRANT OPTION的单独一行列出。上述字段描述与 MySQL 的INFORMATION_SCHEMA.USER_PRIVILEGES视图保持了一致。而从 StarRocks FE 的源码实现看这 4 个字段的实际 SQL 列类型由 UserPrivilegesSystemTable.java 中的表构建器builder定义builder() .column(GRANTEE, TypeFactory.createVarcharType(81)) .column(TABLE_CATALOG, TypeFactory.createVarcharType(FN_REFLEN)) .column(PRIVILEGE_TYPE, TypeFactory.createVarcharType(NAME_CHAR_LEN)) .column(IS_GRANTABLE, TypeFactory.createVarcharType(3)) .build(), TSchemaTableType.SCH_USER_PRIVILEGES);结合SystemTable中的常量见 SystemTable.javapublic static final int FN_REFLEN 512; public static final int NAME_CHAR_LEN 2048;可以得出user_privileges的实际列类型列名实际类型源码最大长度语义GRANTEEVARCHAR81被授予权限的用户名称格式形如userhostTABLE_CATALOGVARCHAR512FN_REFLEN目录名称MySQL 兼容语义下恒为defPRIVILEGE_TYPEVARCHAR2048NAME_CHAR_LEN权限类型名称IS_GRANTABLEVARCHAR3YES或NO3 个字符该表在 FE 中通过TSchemaTableType.SCH_USER_PRIVILEGES这个 Thrift 枚举标识其系统表类型说明user_privileges属于 StarRocks 中的 Schema TableTable.TableType.SCHEMA其元数据由 FE 维护、通过information_schema命名空间对外暴露并不对应任何物理存储。三、如何查询该视图user_privileges属于 StarRocks 的information_schema数据库内建 Catalogdefault_catalog可以直接通过标准 SQL 查询例如-- 查看所有字段 SELECT * FROM information_schema.user_privileges; -- 按需选择字段 SELECT GRANTEE, TABLE_CATALOG, PRIVILEGE_TYPE, IS_GRANTABLE FROM information_schema.user_privileges; -- 结合过滤条件使用 SELECT * FROM information_schema.user_privileges WHERE GRANTEE root% AND IS_GRANTABLE YES;从 InfoSchemaDb.java 的源码可以看到user_privileges在isInternalCatalog(catalogName)为真的情况下被注册为系统表。而 UserPrivilegesSystemTable.java 中create(String catalogName)接受 catalog 名作为参数SystemId.USER_PRIVILEGES_ID为其系统表 ID说明该视图的设计目标是可供多 catalog 场景下的信息架构访问外部 Catalog 的information_schema同样会携带该表结构。另外在测试代码 CatalogConnectorMetadataTest.java 中user_privileges也出现在 FE 默认内建系统表清单的断言列表中进一步印证了该视图默认随information_schema一起注册。四、为何是占位视图StarRocks 与 MySQL 权限模型的差异官方文档明确给出:::note提示「This view does not apply to the available features in StarRocks」该视图不适用于 StarRocks 当前支持的功能其根本原因在于StarRocks 的权限模型与 MySQL 并不相同MySQL 语义user_privileges描述的是“授予用户的、可在全局级别生效的权限”这一概念权限以GRANTEEuserhost为粒度组织。StarRocks 实际模型StarRocks 使用基于 RBAC基于角色的访问控制Role-Based Access Control的权限体系权限通过GRANT/REVOKE命令授予用户User或角色Role并且权限作用域覆盖全局Global、库级Database、表级Table、列级Column等多个层级。从源码实现看权限管理由com.starrocks.authorization.AuthorizationMgr统一负责见 AuthorizationMgr.java 中关于WITH GRANT OPTION的权限校验逻辑其内部权限结构并不能被user_privileges的 4 个固定字段仅覆盖全局权限、且以用户为粒度完整表达。因此user_privileges在 StarRocks 中仅保留了 MySQL 兼容的表结构与字段语义并不返回 StarRocks 实际的授权数据属于典型的“占位视图”。在测试用例CatalogConnectorMetadataTest中它只是作为内建系统表清单的一员被断言存在并没有任何针对其行数据的查询验证——这与它“仅占位、无数据”的定位一致。五、获取真实权限信息的正确姿势既然user_privileges不可用那么在 StarRocks 中查询用户/角色真实权限应使用以下原生方式SHOW GRANTS命令查询当前用户或指定用户的权限这是查看用户授权最直接的命令。其语法解析与权限校验分别实现在 Analyzer.java 与 AuthorizerStmtVisitor.java 中。SHOW GRANTS FOR ROLE查询某个角色的权限详情。SHOW USERS/ 相关角色视图结合用户与角色信息核对授权归属。information_schema中其他权限相关系统表StarRocks 在information_schema中还注册了table_privileges、schema_privileges、column_privileges等权限视图见 InfoSchemaDb.java 中的TablePrivilegesSystemTable、SchemaPrivilegesSystemTable注册可用于按库/表/列粒度查询权限信息。判断某个视图是否可用的小技巧参考 SystemTable.java 中的QUERY_FROM_LEADER_TABLES常量——真正承载查询数据的系统表会被列入其中而user_privileges不在该集合中也从未在任何测试中被断言返回数据行可作为其“仅占位”的佐证之一。六、总结与使用建议问题结论user_privileges能否返回 StarRocks 真实权限不能。官方文档明确标注为不适用于当前功能的占位视图。该视图的字段结构是什么4 个字段GRANTEE、TABLE_CATALOG、PRIVILEGE_TYPE、IS_GRANTABLE全部为 VARCHAR 类型与 MySQL 兼容。它的意义是什么保持information_schema与 MySQL 的形态兼容便于 MySQL 生态工具对元数据视图的枚举与探测。查看真实权限应该用什么使用SHOW GRANTS等原生命令或查询table_privileges、schema_privileges等已实现的权限系统表。最终使用建议在编写跨数据库兼容的查询或使用 BI 工具探测元数据时可以照常枚举information_schema.user_privileges以确保 MySQL 兼容性但在实际做 StarRocks 权限审计、权限回收排查时不要依赖该视图的数据应改用SHOW GRANTS等原生权限查询命令以获得真实、完整的授权信息。参考资源官方文档user_privileges英文、user_privileges中文系统表实现UserPrivilegesSystemTable.java注册入口InfoSchemaDb.java系统表基类SystemTable.java权限管理核心AuthorizationMgr.java【免费下载链接】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），仅供参考