随着国产数据库替代进程加速，大量企业将核心业务从 MySQL 迁移至人大金仓 KingbaseES。然而，异构数据库之间的概念差异往往成为迁移“暗礁”。尤其是 Database、Schema、User 这三个基础但易混淆的核心对象，在 MySQL 与 KingbaseES 中有着根本性不同。本文从三者的定义、关系及迁移要点逐一剖析，帮助开发与运维人员避坑。

Database：物理容器 vs 逻辑命名空间

在 MySQL 中，Database 是一个物理存储单元，每个 Database 对应独立的文件目录。创建 CREATE DATABASE db1 即分配独立的数据文件空间，同时 USE db1 可直接切换。MySQL 的设计中，Database 与 Schema 近乎等价（CREATE SCHEMA 是 CREATE DATABASE 的同义词）。

而在 KingbaseES（基于 PostgreSQL 内核）中，Database 是数据库服务（Cluster）内的顶级隔离单元，不同 Database 之间完全不共享数据。一个 KingbaseES 实例可包含多个 Database，但无法像 MySQL 那样跨库查询。例如，跨库访问需借助 dblink 或 postgres_fdw 扩展。迁移时需注意：MySQL 中多个 Database 对应 KingbaseES 的多个 Database，而非 Schema。若原系统频繁跨库 JOIN，应在 KingbaseES 中合并为同一 Database 下的多个 Schema，或改用应用层逻辑。

Schema：MySQL 的缺失与 KingbaseES 的核心

MySQL 长期以来未正式支持 Schema 概念——8.0 之前，SCHEMA 完全等同于 DATABASE，且没有独立的对象层级。这导致许多开发者将表直接放在 Database 根目录下。

KingbaseES 则沿袭 Oracle/PostgreSQL 的经典三层结构：实例（Cluster）→ Database → Schema → 对象（表、视图等）。一个 Database 下可包含多个 Schema，每个 Schema 可独立管理权限和命名空间。典型用法是：public 作为默认 Schema，用户可创建 finance、sales 等逻辑隔离的 Schema。迁移时最大的陷阱：MySQL 中同一 Database 下的表，在 KingbaseES 中应置于 Schema 下。若直接移植，所有表会挤入 public Schema，既造成命名冲突，也无法实现权限精细化管控。建议将 MySQL 原库中的业务分组映射为 KingbaseES 的 Schema，如原 MySQL 的 order_db 中的 users 表对应 KingbaseES 的 order_db.public.users，或新建 order_schema.users。

User：权限模型从扁平到角色体系

MySQL 的用户体系相对“朴实”：用户直接绑定全局或数据库级权限（GRANT SELECT ON db1.* TO 'user1'@'host'），没有独立的角色概念（8.0 虽引入角色，但使用率低）。用户可通过 mysql.user 表全局管理，权限粒度较粗。

KingbaseES 则采用基于角色的访问控制（RBAC）：用户（User）可归属一个或多个角色（Role），角色继承权限链。默认的 PUBLIC 角色拥有对 public Schema 的 CREATE、USAGE 权限，这常成为安全漏洞。迁移时需要重新设计权限策略：MySQL 的应用直接使用“用户名+密码”连接某个 Database，对应 KingbaseES 中需创建同名用户并赋予对应 Schema 的 USAGE 和权限。特别要注意的是，KingbaseES 中 CREATE USER 默认不带权限，需手动 GRANT CONNECT ON DATABASE 才能登录，且用户与数据库无绑定关系。迁移后常出现“用户创建了，但连不上”的异常，根源在于此。

迁移实战要点总结

从 MySQL 迁移至 KingbaseES 时，建议按以下步骤处理这三个对象：

  1. 映射关系重塑：MySQL 的一个 Database → KingbaseES 的一个 Database；MySQL 该 Database 下所有表 → 按业务主题拆分为多个 Schema（或统一放入 public Schema）。
  2. Schema 先行：在 KingbaseES 目标库中提前创建 Schema，避免表名冲突。建议沿用原表命名，但使用 schema.table 格式。
  3. 用户重建：逐一创建 KingbaseES 用户，授予 CONNECT 权限和相应 Schema 的 USAGE、SELECT、INSERT 等权限。移除冗余的 PUBLIC 权限以提升安全性。
  4. 测试验证：执行 \dn+ 检查 Schema 归属，\du+ 查看用户权限，确保应用连接串中的 search_path 设置正确（KingbaseES 中 search_path 决定 Schema 查找顺序，必须与预期一致）。

一位资深 DBA 向记者表示：“很多团队迁移失败，根源在于把 KingbaseES 当 MySQL 用。Database 不再是一个文件夹，而是一个独立世界；Schema 才是真正的逻辑容器。不理解这三者的差异，迁移后的系统性能和安全都可能大打折扣。”

随着信创产业进入深水区，掌握 Database、Schema、User 在 MySQL 与 KingbaseES 中的本质区别，已成为数据库工程师的必修课。只有从底层概念上“讲透”，才能让国产数据库迁移真正“走通”。