【金仓数据库】ksql 指南(三) —— 创建与管理表空间和模式
二、模式管理:给数据库对象 “建个逻辑文件夹”
模式是 KingbaseES 中“逻辑隔离”的核心概念,它类似于数据库里的“文件夹”,可以将不同用户的表,视图等对象分开存储,比如 user1 的表放在 schema_user1 模式下,user2 的表放在 schema_user2 模式下,即便表名相同也不会产生冲突,文档里对模式的操作流程有着清晰的阐述,我们按照“创建 - 查看 - 使用 - 权限 - 修改删除”的顺序来展开讲解。
2.1 为什么需要模式?新手必懂的核心作用
在没有创建自定义模式的时候,所有的表会默认保存在 public 模式下(这是系统默认的模式),如果很多用户共同使用一个数据库,就很可能产生“表名冲突”的情况(譬如说两个用户都想创建 user 表),而模式的关键意义就在于此:
对象隔离:不同模式下的对象(表、视图)可重名,互不干扰;
权限控制方面,可以向不同用户赋予不同模式的权限,譬如仅仅允许user1访问schema_user1
管理非常明晰,按照业务模块划分的方式,比如schema_order用于存储订单表,schema_user用于存储用户表。
2.2 创建模式:用 CREATE SCHEMA 语句
文档中给出了模式的创建语法,支持指定所有者、默认权限等,以下是基础和进阶示例:
2.2.1 1. 基础创建:仅指定模式名
在 ksql 交互模式下,执行以下命令创建名为 test_schema 的模式(默认所有者是当前用户):
CREATE SCHEMA test_schema;

执行后提示 CREATE SCHEMA,表示创建成功,该模式会归属到当前连接用户(如 system)。
2.2.2 2. 进阶创建:指定所有者
若需创建一个归属 user1 的模式(让 user1 拥有该模式的所有权限),可添加 AUTHORIZATION 选项:
CREATE SCHEMA test_schema AUTHORIZATION user1;
该命令适用于 “管理员为普通用户创建专属模式” 的场景,避免后续权限配置的麻烦。
2.2.3 3. 特殊场景下,要创建模式并且授权
如果在创建模式的时候还要向其他用户赋予这种模式的使用权,可以利用 GRANT 语句来实现
-- 1. 创建模式,所有者为 system
CREATE SCHEMA test_schema;
-- 2. 给 user1 授予 test_schema 的使用权限和表查询权限
GRANT USAGE, SELECT ON ALL TABLES IN SCHEMA test_schema TO user1;

2.3 查看模式以了解逻辑隔离状态
建模式之后,要利用 ksql 命令来查看模式列表与详情,从而确认创建结果,文档里建议采用 \dn 这一系列命令
2.3.1 1. 在ksql交互模式当中,输入\dn这个命令
在ksql交互模式当中,输入\dn这个命令,就可以显示当前数据库里面包含的所有模式
\dn
执行后会显示类似以下的表格(示例):

2.3.2 2. 查看模式下的对象
若需了解 test_schema 模式下有哪些表,执行以下命令:
-- 方法1:ksql 专用命令(简洁)
\dt test_schema.*
-- 方法2:SQL 语句(详细)
SELECT tablename FROM pg_tables WHERE schemaname = 'test_schema';
\dt test_schema.*:显示test_schema模式下的所有表;- 若模式下无表,会提示
No relations found.,属于正常情况。

2.4 使用模式:切换与访问对象的关键
切换到访问对象的关键创建模式之后,要想在这个模式里创建表或者访问表,首先得知道“模式搜索路径”这个概念,KingbaseES 会按照搜索路径的顺序去查找相关对象,这个地方新手很容易出错
2.4.1 1. 查看当前模式搜索路径
执行以下命令,查看当前的搜索路径:
SHOW search_path;
默认搜索路径为:
search_path = "$user", public

"$user":有一个优先查找与当前用户名同名的模式的情况,比如说当下用户叫 user1,那么它会首先找 user1 这个模式public:如果没有找到同名模式,就要找public模式
2.4.2 2. 更改模式搜索路径,这非常重要,以免找不到对象
如果希望优先访问 test_schema 模式中的对象,可以更改搜索路径
-- 方法1:临时修改(当前会话有效)
SET search_path TO test_schema, public;
-- 方法2:永久修改(当前用户所有会话有效)
ALTER USER current_user SET search_path TO test_schema, public;
- 临时的,关闭 ksql 就会失效,比较适合临时操作。
- 永久修改:需重新连接 ksql 生效,适合长期使用某模式的场景。

显示SET表示修改成功
2.4.3 3. 在模式下创建表
修改搜索路径后,直接创建表会默认存放在 test_schema 模式:
CREATE TABLE user_info (
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL
);
若未修改搜索路径,需在表名前加 “模式名。表名” 指定模式:
CREATE TABLE test_schema.user_info (
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL
);
两种方式创建的表都会归属到 test_schema 模式,可通过 \dt test_schema.* 验证。

2.4.4 4. 访问模式下的表
访问模式下的表时,有两种方式:
- 修改搜索路径后:直接用表名访问(搜索路径会自动匹配模式)
SELECT * FROM user_info;
未修改搜索路径:需加 “模式名。表名” 全称访问:
SELECT * FROM test_schema.user_info;
2.5 模式权限控制:精细化管理访问权限
模式的权限控制是其核心价值之一,包括如何通过 GRANT(授予)和 REVOKE(撤销)命令管理权限,常用权限包括 USAGE(访问权限)、CREATE(创建对象权限)、SELECT(查询表权限)等。
2.5.1 1. 授予模式权限(GRANT)
示例 1:给 user1 授予 test_schema 的 “访问权限” 和 “表查询权限”:
-- 1. 授予访问模式的权限(必须有,否则无法看到模式下的对象)
GRANT USAGE ON SCHEMA test_schema TO user1;
-- 2. 授予查询模式下所有表的权限
GRANT SELECT ON ALL TABLES IN SCHEMA test_schema TO user1;
示例 2:给 user1 授予 “在模式下创建表的权限”:
GRANT CREATE ON SCHEMA test_schema TO user1;
授予后 user1 可在 test_schema 下创建表,但不能修改其他用户的表。

2.5.2 2. 撤销模式权限(REVOKE)
若需收回 user1 对 test_schema 的查询权限,执行以下命令:
REVOKE SELECT ON ALL TABLES IN SCHEMA test_schema FROM user1;
撤销后 user1 仍能看到模式下的表,但无法查询数据,实现 “可见不可查” 的控制。
2.6 修改与删除模式:管理逻辑隔离生命周期
当模式名称需要调整或不再使用时,可执行修改或删除操作,文档中明确了相关语法和注意事项。
2.6.1 1. 修改模式(ALTER SCHEMA)
常用的修改操作是 “重命名”,语法如下:
ALTER SCHEMA test_schema RENAME TO new_test_schema;
执行后提示 ALTER SCHEMA,重命名后模式下的对象(表、视图)会自动归属到新模式名,无需修改表的归属。
2.6.2 2. 删除模式(DROP SCHEMA)
删除模式前需注意:模式下若有对象(表、视图),直接删除会报错,需加 CASCADE 选项级联删除模式及所有对象(高危操作,谨慎使用)。
步骤 1:确认模式下的对象
执行以下命令,查看模式下是否有对象:
\dt new_test_schema.*
若有对象,需确认是否要一并删除(无备份则无法恢复)。
步骤 2:执行删除命令
- 无对象时删除:
DROP SCHEMA IF EXISTS new_test_schema;
有对象时级联删除(谨慎!会删除模式下所有表):
DROP SCHEMA IF EXISTS new_test_schema CASCADE;
执行后提示 DROP SCHEMA,表示删除成功,模式及相关对象会从数据库中永久移除。
2.7 模式常见问题排查
文档中提到了模式操作的典型报错,以下是两种高频问题及解决方案:
问题 1:找不到模式下的表,报错 “关系对象不存在”
报错信息:
ERROR: relation "user_info" does not exist
原因:模式搜索路径未包含目标模式(如 test_schema 不在搜索路径中),数据库默认在 public 模式查找表。
解决方案:修改搜索路径包含目标模式:
SET search_path TO test_schema, public;
问题 2:无权限访问模式,报错 “模式权限被拒绝”
报错信息:
ERROR: permission denied for schema test_schema
原因:当前用户无 test_schema 的 USAGE 权限。
解决方案:由模式所有者或管理员授予 USAGE 权限:
GRANT USAGE ON SCHEMA test_schema TO 当前用户名;