从 MySQL 到 KingbaseES：Database、Schema、User 一次讲透

前言

对于长期使用 MySQL 的开发者或 DBA 来说，初次接触 KingbaseES（金仓数据库）时，可能会对其中的Database、Schema、User等核心概念感到困惑。这些概念在 KingbaseES 中的层级关系、权限模型与 MySQL 存在显著差异，理解这些差异是顺利迁移和运维的关键。

本文将从 MySQL 使用者的视角出发，系统性地对比和讲解 KingbaseES 中Database、Schema、User的概念、关系及最佳实践，帮助你一次理清思路，平滑过渡。

1. 概念对比：MySQL vs KingbaseES

在深入细节之前，我们先从宏观上对比两者在这些核心概念上的不同。

简单来说，可以这样理解层级关系：

• MySQL:实例 (Instance)->数据库/模式 (Database/Schema)->表 (Table)
• KingbaseES:集群 (Cluster)->数据库 (Database)->模式 (Schema)->表 (Table)

KingbaseES 在Database和Table之间多了一层Schema，这带来了更好的组织性和灵活性。

2. Database：独立的王国

在 KingbaseES 中，Database 是最高级别的逻辑隔离单位。这与你熟悉的 MySQL 数据库概念有本质区别。

2.1 核心特性

1. 完全隔离：不同的 Database 之间无法直接进行 SQL 查询（如JOIN,UNION）。它们拥有独立的系统目录、用户定义对象，甚至连接也是独立的。
2. 独立连接：客户端连接 KingbaseES 时，必须指定一个 Database（类似于 MySQL 的USE database，但是在连接时就确定）。常见的连接字符串格式为jdbc:kingbase8://host:port/database_name。
3. 专属属主：每个 Database 都有一个属主（Owner），通常是创建它的用户。属主自动拥有该数据库的所有权限。

2.2 操作示例

-- 1. 创建数据库 (需要 CREATEDB 权限)CREATEDATABASEsales_db ENCODING'UTF8'LC_COLLATE'zh_CN.UTF-8'LC_CTYPE'zh_CN.UTF-8'TEMPLATE template0 OWNER sales_admin;-- 2. 查看所有数据库\l-- 或SELECTdatnameFROMpg_database;-- 3. 修改数据库属主ALTERDATABASEsales_db OWNERTOnew_admin;-- 4. 删除数据库 (需要权限，且不能有活跃连接)DROPDATABASEIFEXISTSsales_db;

迁移提示：在 MySQL 中，你可能习惯将不同业务的数据放在同一个实例的不同 Database 中，并且可以方便地跨库查询。迁移到 KingbaseES 时，需要重新评估：

• 如果业务模块间确实需要频繁跨库关联查询，应考虑将它们合并到同一个 KingbaseES Database中，利用Schema进行逻辑分离。
• 如果业务模块完全独立，无需联合查询，则可以保持为不同的 Database，享受物理隔离带来的安全性和管理便利。

3. Schema：数据库内的命名空间

Schema 是 KingbaseES 中一个非常强大的特性，它解决了“一个数据库内如何优雅地组织大量对象”的问题。

3.1 核心特性

1. 逻辑分组：可以将表、视图、索引、函数、类型等数据库对象分组到不同的 Schema 下。例如，可以为hr（人力资源）、finance（财务）、report（报表）分别创建 Schema。
2. 权限控制：可以针对整个 Schema 授予权限（如USAGE,CREATE），简化权限管理。
3. 搜索路径 (search_path)：这是一个关键概念。当你执行SELECT * FROM my_table;时，KingbaseES 会按照search_path中定义的 Schema 顺序去查找my_table。默认的search_path通常是"$user", public，意味着它会先找与当前用户同名的 Schema，再找publicSchema。

3.2 操作示例

-- 1. 创建 SchemaCREATESCHEMAhr;CREATESCHEMAfinanceAUTHORIZATIONfinance_user;-- 指定属主-- 2. 在指定 Schema 中创建表CREATETABLEhr.employees(idSERIALPRIMARYKEY,nameVARCHAR(100)NOTNULL,department_idINT);CREATETABLEfinance.invoices(invoice_id BIGSERIALPRIMARYKEY,amountDECIMAL(15,2),issue_dateDATE);-- 3. 查看当前搜索路径SHOWsearch_path;-- 默认可能是: "$user", public-- 4. 修改当前会话的搜索路径 (方便查询)SETsearch_pathTOhr,public;-- 现在可以直接查询 employees，而无需加 hr. 前缀SELECT*FROMemployees;-- 5. 为用户设置默认搜索路径ALTERUSERapp_userSETsearch_path=hr,public;-- 6. 删除 Schema (CASCADE 会删除其下所有对象)DROPSCHEMAIFEXISTSold_schemaCASCADE;

迁移提示：对于从 MySQL 迁移过来的应用，最常见的做法是将所有表都放在publicSchema 中，这可以快速兼容。但从长远看，合理规划和使用 Schema 能让数据库结构更清晰、更易于管理。

4. User/Role：统一的权限主体

KingbaseES 遵循 PostgreSQL 的模型，使用Role（角色）来统一管理用户和组。一个拥有LOGIN属性的 Role 就是一个 User。

4.1 核心特性

1. 角色继承：角色可以继承其他角色的权限，实现权限的复用和层级管理。
2. 灵活的权限：权限可以授予给角色，角色可以再被授予给其他角色或用户。权限粒度可以细到具体某张表、某个列。
3. 集群级别：用户/角色是在集群级别创建的，但他们的权限作用范围可以是具体的 Database、Schema 或对象。

4.2 操作示例

-- 1. 创建具有登录权限的用户（等同于 MySQL 的 CREATE USER）CREATEUSERapp_userWITHPASSWORD'StrongPass123!';-- 或者使用 ROLE（加上 LOGIN 属性）CREATEROLE app_userWITHLOGIN PASSWORD'StrongPass123!';-- 2. 创建角色（组），用于权限分组CREATEROLE read_only;CREATEROLE data_writer;-- 3. 授予角色权限-- 授予 read_only 角色对 hr Schema 下所有现有表的 SELECT 权限GRANTUSAGEONSCHEMAhrTOread_only;GRANTSELECTONALLTABLESINSCHEMAhrTOread_only;-- 让 data_writer 角色可以在 finance Schema 中创建表并插入数据GRANTCREATE,USAGEONSCHEMAfinanceTOdata_writer;GRANTINSERT,UPDATEONALLTABLESINSCHEMAfinanceTOdata_writer;-- 4. 将角色权限授予用户GRANTread_onlyTOapp_user;GRANTdata_writerTOapp_user;-- 5. 查看用户权限\du app_user-- 命令行查看-- 或通过系统视图查询SELECTr.rolname,array_agg(b.rolname)asmember_ofFROMpg_roles rLEFTJOINpg_auth_members mONr.oid=m.memberLEFTJOINpg_roles bONm.roleid=b.oidWHEREr.rolname='app_user'GROUPBYr.rolname;-- 6. 修改用户密码ALTERUSERapp_userWITHPASSWORD'NewStrongPass456!';-- 7. 删除用户DROPUSERIFEXISTSapp_user;

迁移提示：MySQL 的权限管理通常更直接（GRANT ALL ON db.* TO 'user'@'host'）。迁移到 KingbaseES 后，需要花时间设计角色体系。一个好的实践是：先创建功能角色（如read_only,read_write），再创建业务用户，并将功能角色授予业务用户。

5. 最佳实践与迁移建议

5.1 命名规范

• Database: 使用小写、下划线，代表一个完整的业务系统或完全独立的应用，如order_center,crm_system。
• Schema: 使用小写，代表一个业务模块或功能域，如inventory,billing,analytics。
• User/Role: 使用小写，用户以_user结尾（如report_user），角色以_role结尾或描述权限（如dev_readwrite_role）。

5.2 权限设计四步法

1. 创建业务数据库：CREATE DATABASE myapp OWNER admin_user;
2. 创建业务 Schema：在数据库内，CREATE SCHEMA module1 AUTHORIZATION admin_user;
3. 创建功能角色：CREATE ROLE module1_read_only;然后授予该 Schema 的USAGE和表SELECT权限。
4. 创建应用用户：CREATE USER app1 WITH PASSWORD 'xxx';然后GRANT module1_read_only TO app1;

5.3 连接与搜索路径配置

在应用连接配置（如 JDBC URL）或用户属性中，设置好默认的search_path，可以避免在 SQL 中写冗长的 Schema 前缀。

# JDBC 连接示例 jdbc:kingbase8://localhost:54321/myapp_db?currentSchema=hr&user=app_user&password=xxx

5.4 迁移检查清单

1. 分析现有 MySQL 实例中 Database 间的关联关系，决定在 KingbaseES 中是合并为一个 Database（用 Schema 分隔）还是保持为多个 Database。
2. 为新的 KingbaseES 数据库设计清晰的 Schema 结构。
3. 将 MySQL 的用户权限映射为 KingbaseES 的角色体系。
4. 修改应用程序的连接字符串，指定正确的 Database 和（可选的）currentSchema。
5. 测试应用的查询、事务和权限控制是否正常工作。

6. 总结

从 MySQL 到 KingbaseES 的迁移，在Database、Schema、User这三个核心概念上需要完成一次思维转换：

• Database从“可互联的仓库”变成了“隔离的王国”，规划时需慎重。
• Schema从“Database 的同义词”变成了“王国内的行政区划”，是组织代码和权限的利器。
• User/Role从“用户账号”融入了更强大的“角色系统”，让权限管理更加灵活和精细。

理解并善用这些概念，不仅能帮助你顺利完成迁移，更能为你的 KingbaseES 数据库奠定一个清晰、安全、易于维护的架构基础。

希望这篇讲解能帮助你一次理清这些关键概念，在迁移之路上更加从容。