KingbaseES数据库：从创建到实战，一文搞定物理存储与逻辑隔离

xcLeigh
35 阅读18分钟

KingbaseES数据库：从创建到实战，一文搞定物理存储与逻辑隔离

本文围绕 KingbaseES 数据库的表空间与模式展开，先讲解表空间管理：从 Linux/Windows 系统的存储路径创建与权限配置入手，详解用 CREATE TABLESPACE 语句创建表空间的方法，介绍通过 \db/\db + 命令查看表空间信息，说明指定表空间创建表的实操及验证方式，还涵盖表空间修改、删除流程与常见权限 / 非空报错解决方案。再阐述模式管理：分析模式解决表名冲突、实现权限控制与清晰管理的核心作用，分步说明模式的创建、查看、搜索路径调整、对象创建与访问，以及权限授予 / 撤销、修改删除操作，同时给出模式对象找不到、权限不足等问题的解决办法。最后强调二者配合使用的优势，为后续表的管理奠定基础，并补充二者结合的业务场景与进阶避坑技巧。

在这里插入图片描述

引言

学会数据库基本操作后，接下来就得深入琢磨“存储层面的表空间”和“逻辑层面的模式”了。表空间负责规划数据文件的物理存储路径，模式则能给数据库里的表、视图这些对象做逻辑隔离，把两者结合起来用，本地KingbaseES数据库跑起来会更高效、更安全。这篇文章就分两部分，把表空间和模式的创建、查看、使用还有删除流程讲透，每个步骤都会给大家举实际操作的例子，还会提醒大家怎么避开常见错误。

一、表空间管理：给数据 “找个合适的存储位置”

在KingbaseES里，表空间可是“物理存储”体系的核心。说白了，它就是指定数据库文件存在哪儿的目录。咱们可以把经常读写的大表放到高速磁盘对应的表空间里，那些不常用的归档数据就丢进普通磁盘的表空间，这样能大大提升磁盘的IO性能。文档里已经把表空间的各项操作步骤说清楚了，下面咱们就按“创建 - 查看 - 使用 - 修改/删除”的顺序一步步来讲。

1.1 前置准备：确认存储路径与权限

创建表空间前，有两个条件必须满足。一是本地存储路径得提前建好，二是KingbaseES的运行用户（默认是kingbase用户）得有这个路径的读写权限。这一点文档里提了好多次，要是没做到，肯定会弹出“权限不足”的错误提示。

1.1.1 1. 创建本地存储路径（以 Linux 为例）

假设咱们要建一个叫test_ts的表空间，打算把数据文件存在/opt/kingbase/tablespace/test_ts这个目录里，那就执行下面这些命令来创建路径（得有root权限或者sudo权限才行）：

# 1. 创建多级目录
mkdir -p /opt/kingbase/tablespace/test_ts
# 2. 给 kingbase 用户授权（关键！否则数据库无法读写该路径）
chown -R kingbase:kingbase /opt/kingbase/tablespace/test_ts
chmod -R 755 /opt/kingbase/tablespace/test_ts
  • mkdir -p：就算上级目录不存在，也能把多级目录一次性创建出来；
  • chown -R：把这个路径的所有者改成kingbase用户，也就是数据库的运行用户；
  • chmod -R 755：保证kingbase用户能读、能写、能执行，其他用户只能读和执行。
1.1.2 2. Windows 系统路径准备

要是用的是Windows系统，想把表空间路径设为D:\Tools\Kingbase\ES\tablespace\test_ts，那就这么操作：

  1. 手动在资源管理器里建好这个目录；
  2. 右键点击目录，选择“属性”，再点“安全”，然后添加kingbase用户（要是还没创建，得先在“计算机管理”里建好），并且给它“完全控制”的权限。

1.2 创建表空间：用 CREATE TABLESPACE 语句

1.2.1 1. 基础语法
CREATE TABLESPACE 表空间名 LOCATION '本地存储路径';
  • 表空间名：自己起个名字就行，比如test_ts，但得符合标识符规则，不能有特殊字符；
  • LOCATION '本地存储路径'：这个路径必须是提前建好的，比如Linux系统里的/opt/kingbase/tablespace/test_ts，Windows系统里的'D:/Kingbase/tablespace/test_ts'，要注意Windows路径得用/或者\\。
1.2.2 2. 实操示例：创建 test_ts 表空间

  1. 先用ksql连接本地数据库，比如连接kingbase库：

    ksql -d kingbase -U system

  2. 执行创建表空间的命令（以Linux系统为例）：

    CREATE TABLESPACE test_ts LOCATION '/opt/kingbase/tablespace/test_ts';

    要是Windows系统，命令就改成这样（路径用/分隔）：

    CREATE TABLESPACE test_ts LOCATION 'D:\Tools\Kingbase\ES\tablespace\test_ts';

  3. 怎么确认创建成功呢？执行命令后如果提示CREATE TABLESPACE，那就说明表空间建好了（ksql对成功的DDL语句只会返回操作类型）。

1.2.3 3. 进阶：指定表空间所有者

表空间默认的所有者是当前创建它的用户，比如system。要是想把其他用户（比如user1）设为所有者，加上OWNER这个选项就行。

CREATE TABLESPACE test_ts LOCATION '/opt/kingbase/tablespace/test_ts' OWNER user1;

这种操作在多用户一起协作的时候特别有用，能把表空间的权限归属弄得明明白白。

1.3 查看表空间：了解存储状态

建好了表空间，咱们得用ksql命令看看表空间的列表和详细情况，确认一下路径、大小这些信息。建议大家用\db这一系列命令。

1.3.1 1. 查看所有表空间列表（\db 命令）

在ksql的交互模式里，执行下面这个命令，就能列出本地所有表空间的核心信息：

\db

执行后会显示类似这样的表格（示例）： 表格包含表空间名称、所有者、位置等核心信息，清晰呈现本地所有表空间的基础情况，比如可看到test_ts表空间对应的所有者为system，位置为/opt/kingbase/tablespace/test_ts等内容。

1.3.2 2. 查看表空间详情（\db+ 命令）

要是想知道表空间的“大小、使用情况”这些详细信息，就在\db后面加个+，语法是这样的：

\db+ 表空间名

比如查看test_ts的详情：

\db+ test_ts

执行后会显示类似这样的信息： 除了表空间名称、所有者、位置外，还会展示大小、描述、使用情况等详细内容，例如能看到test_ts表空间的大小为0 bytes（初始状态），以及该表空间目前暂无数据存储的使用情况说明等。

1.4 使用表空间：给表指定存储位置

创建表空间的最终目的，就是把表、索引这些对象存到指定的路径里。文档里说，只要在创建表的时候用TABLESPACE选项指定表空间就行。

1.4.1 1. 示例：在 test_ts 表空间创建表

要是咱们想建一个叫user_info的表，并且规定它的数据文件要放在test_ts表空间里，就可以参考下面这条命令：

CREATE TABLE user_info (
    id INT PRIMARY KEY,
    name VARCHAR(50) NOT NULL,
    age INT
) TABLESPACE test_ts;
  • TABLESPACE test_ts：这是关键选项，用来指定表的存储表空间；
  • 执行完之后如果提示CREATE TABLE，那就说明表已经在test_ts表空间里创建成功了。
1.4.2 2. 验证表的表空间归属

建完表之后，咱们可以用\d+命令看看表的详情，确认一下表空间是不是选对了：

\d+ user_info

执行后会显示user_info表的结构信息，包括字段名、类型、约束等，同时在表的详细信息中会明确标注其所属表空间为test_ts，以此确认表的表空间归属正确。

1.5 修改与删除表空间：管理存储生命周期

当表空间的路径需要调整，或者不再用它的时候，就得执行修改或者删除操作。文档里把相关的语法和注意事项都说明白了。

1.5.1 1. 修改表空间（ALTER TABLESPACE）

常用的修改操作主要是“重命名”和“修改所有者”，语法如下：

  • 重命名表空间：

    ALTER TABLESPACE test_ts RENAME TO new_test_ts;

    比如在这个例子里，把test_ts改成new_test_ts，执行后提示ALTER TABLESPACE就说明改好了。重命名之后，原来表空间下的表会自动归到新的表空间名下面，存储路径是不变的。

  • 修改表空间所有者：

    ALTER TABLESPACE new_test_ts OWNER TO user1;

    这个命令能把表空间的所有者从system改成user1，在需要交接权限的时候特别有用。

1.5.2 2. 删除表空间（DROP TABLESPACE）

删除表空间可是个“高危操作”，一定要确保表空间下面没有表、索引这类任何对象，不然肯定会报错。文档里建议，先看看表空间的使用情况，再动手删除。

步骤 1：检查表空间下的对象

执行下面这条SQL语句，看看new_test_ts表空间下面有没有表：

SELECT tablename FROM pg_tables WHERE tablespace = 'new_test_ts';

要是返回的结果是空的，就说明里面没有表；要是有表，得先把表删掉，或者把表迁移到其他表空间（比如用ALTER TABLE 表名 SET TABLESPACE pg_default;这个命令）。

步骤 2：执行删除命令

确认里面没有对象之后，就可以执行删除命令了（建议加上IF EXISTS，这样删除不存在的表空间时就不会报错）：

DROP TABLESPACE IF EXISTS new_test_ts;

执行后提示DROP TABLESPACE，就表示删除成功了。不过要注意，本地的存储路径还会保留着，得手动去删，数据库不会自动删掉物理目录。

1.6 表空间常见问题排查

文档里提到了表空间操作时常见的错误，下面就给大家说两种高频问题以及对应的解决办法：

问题 1：创建表空间报错 “目录权限被拒绝”

报错信息：

ERROR:  could not set permissions on directory "/opt/kingbase/tablespace/test_ts": Permission denied

原因：kingbase用户没有这个存储路径的读写权限。
解决方案：重新执行权限授权命令（以Linux为例）：

chown -R kingbase:kingbase /opt/kingbase/tablespace/test_ts
chmod -R 755 /opt/kingbase/tablespace/test_ts
问题 2：删除表空间报错 “表空间非空”

报错信息：

ERROR:  tablespace "test_ts" is not empty

原因：表空间下面还有表、索引这些对象。
解决方案：先把对象删掉或者迁移走，再执行删除命令（可以参考1.5.2步骤1的方法）。

二、模式管理：给数据库对象 “建个逻辑文件夹”

在KingbaseES里，模式是实现“逻辑隔离”的核心概念，它就像数据库里的“文件夹”一样。咱们可以把不同用户的表、视图这些对象分开存，比如把user1的表放在schema_user1模式下，user2的表放在schema_user2模式下，就算表名一样也不会冲突。文档里把模式的操作流程讲得很清楚，下面咱们就按“创建 - 查看 - 使用 - 权限 - 修改删除”的顺序来聊聊。

2.1 为什么需要模式？新手必懂的核心作用

要是没创建自定义模式，所有的表都会默认存在public模式里（这是系统自带的默认模式）。要是很多人共用一个数据库，很容易就会出现“表名冲突”的情况，比如两个用户都想建一张叫user的表。而模式的关键作用就在这儿：

  1. 对象隔离：不同模式下的对象，像表、视图这些，就算名字一样也没关系，互相不会干扰；
  2. 权限控制：咱们可以给不同用户赋予不同模式的权限，比如只让user1访问schema_user1；
  3. 管理清晰：可以按照业务模块来划分模式，比如用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

执行后会显示类似这样的表格（示例）： 表格包含模式名称、所有者等信息，能清晰看到当前数据库中的所有模式，例如可看到test_schema模式，其所有者为system，同时还有默认的public模式等。

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 当前用户名;

三、总结：表空间与模式的配合使用

学完这篇文章，大家应该掌握了表空间和模式的核心操作：

  • 表空间：管的是“物理存储”，负责规划数据文件的路径，提升IO性能；
  • 模式：管的是“逻辑隔离”，负责给数据库对象分类存放，避免冲突，还能精细化控制权限。

在实际应用中，两者经常一起用。比如创建“订单业务表空间ts_order”和“订单业务模式schema_order”，把和订单相关的表都放在里面。这样一来，既提升了存储性能，又让业务对象的管理变得更清晰。

avatar
文章
阅读
粉丝