1.3 术语体系与逻辑结构

1.3 术语体系与逻辑结构

本节摘要：集群、实例、数据库、模式、表空间、OID——这些词在 openGauss 里有严格的层级关系。本章用一套可查证的命令把坐标系立起来，顺手澄清三组最容易混用的术语。

一个反例：术语不统一，会议就变成辩论赛

某项目需求评审会上，应用方说"我们要新建一个实例"，运维理解为"再装一套数据库软件"，安全方在整改单里写的却是"新增数据库并纳管"。半小时后大家发现三方说的根本不是同一层东西。这类事故的根源不是技术，是坐标系。openGauss 沿用的层级模型是：物理机上先有数据库集群（一套数据目录 + 一组进程，注意这里的"集群"指单机管理域，与主备集群的"集群"又是另一个语境），集群里含一个实例进程组，实例下按目录划分多个数据库，数据库内用模式组织对象，对象物理上落到表空间对应的存储位置。把这条链背下来，会议效率立竿见影。

从命令出发建立坐标系

概念最好用查询来记。下面的会话把每一层都摸一遍：

-- 当前实例版本与启动时间
SELECT version();
-- 实例下有哪些数据库
SELECT datname, oid FROM pg_database ORDER BY oid;
-- 当前在哪个库，库下有哪些模式
SELECT current_database();
SELECT nspname FROM pg_namespace WHERE nspname NOT LIKE 'pg_%' AND nspname <> 'information_schema';
-- 表空间：逻辑对象与磁盘位置之间的桥梁
SELECT spcname, pg_tablespace_location(oid) FROM pg_tablespace;
​

逐层解读：pg_database 的 oid 是数据库对象的全局唯一标识，备份恢复、主备一致性校验时对账用的就是它而不是库名；模式（schema）是库内的命名空间，Oracle 背景的同事可以近似理解为"用户即模式"，但 openGauss 里用户与模式是两个对象，只是常成对创建；表空间允许你把索引、大表指到独立磁盘卷，是存储分层（高速盘放热数据、大容量盘放归档）的抓手。

三组最容易混的术语

核心机制术语提前打底

后面章节会反复出现三个词，这里先挂个号。WAL（预写日志）：任何数据页修改先记日志再落数据页，崩溃恢复靠重放 WAL——第 2、5 章的主角。Checkpoint（检查点）：把脏页批量刷盘并记录日志位点，决定崩溃后要重放多少日志——第 7 章调优参数表里它会反复出现。MVCC（多版本并发控制）：读写互不阻塞的根基，每行数据带版本信息，按快照判断可见性——第 3 章整章围绕它展开。三者的关系一句话：WAL 保持久，Checkpoint 控恢复时长，MVCC 管并发。

一个案例把术语串起来。背景：某系统夜里批量任务把库拖慢，值班新人描述故障时说"实例挂了"。排查第一步是核对术语：进程都在、端口通、能建连接，实例根本没挂，慢的是特定库里的特定表。第二步用坐标系定位：pg_stat_activity 看等待事件，发现全部压在一张报表表上；第三步查表空间布局，发现报表表与核心业务表共享同一块盘，批量扫描把 IO 抢光了。处置：把报表表迁移到独立表空间所在的大容量盘，批量窗口错峰。复盘时写报告：不是"实例故障"，是"对象级 IO 争抢"——术语精确，归因才精确。

权限模型的坐标系补充

术语体系还有一条纵向轴：角色与权限。库级 CONNECT、模式级 USAGE、表级 SELECT/INSERT/UPDATE/DELETE、列级授权，四层各管一段。常见的翻车是把表的权限授给了用户，却忘了给模式 USAGE，应用连上后报"权限拒绝"却查不到原因。交付清单里建议固定一条：授表权限前，先核对模式 USAGE 与库 CONNECT 是否齐备。

常见误解澄清：三个流传很广的说法

误解一："一个实例就是一个数据库。"错。实例是进程与内存的整体，库里可以有许多数据库；连接串连接的是实例中的某个数据库。混淆两者的典型事故：以为"重启实例"等于"重启某个库"，结果整台实例上的所有库一起闪断。误解二："表空间就是一块磁盘。"不准确。表空间是逻辑对象到目录位置的映射，一个表空间可以横跨目录软链到不同盘，同一个盘上也可以有多个表空间。做 IO 规划时，看的是物理盘的拓扑，表空间只是分配的抓手。误解三："模式等同于用户。"在 openGauss 里两者是独立对象，只是习惯上成对创建。权限授予时尤其要分清：给用户的权限不会自动落到他同名模式下的新表上，默认权限要显式配置——6.1 节的 ALTER DEFAULT PRIVILEGES 就是为此。

命名规范的交付价值

术语坐标系的最后一公里是命名规范。交付项目的命名规范建议包含四条：库名带环境与业务域（生产与预发的库一眼可辨）；模式名与业务模块对齐（权限授予按模式批量进行，模块边界即权限边界）；对象名统一小写下划线（消灭大小写引号陷阱）；临时对象带前缀与生命周期标记（批处理的临时表用完即删，避免统计信息与清理策略被临时对象污染）。命名规范看似事小，但权限批量授予、监控按模式聚合、迁移按清单核对，全部建立在命名可解析的基础上。一个真实对照：两个同规模项目，命名规范健全的那个，迁移时对象核对只用了另一个三分之一的时间——规范是给自己省时间，不是给文档凑章节。

自查演练：五分钟建立你们环境的坐标系

拿生产环境做一次五分钟自查，逐条回答：实例里有几个库、每个库有几个业务模式、最大的三个表分布在哪些表空间、业务账号分别能连哪些库。如果四个问题都答不上来，说明你们的术语坐标系还没有落到可查询的清单上。把答案整理成一页"环境坐标系卡"贴进运维手册——排障时它是最先被翻开的页。这份卡片还有个隐性价值：新人交接时，讲一遍卡片就完成了术语体系的入门培训，比通读文档快得多。

概念辨析再加一题：库、租户与隔离级别

做多租户或SaaS类系统时，"一个租户一个库还是一个租户一个模式"是绕不开的架构题，答案取决于隔离强度的需求。库级隔离：数据彻底分家、备份恢复可按租户独立操作、权限天然边界清晰，代价是库数量膨胀后的连接管理与监控聚合压力——租户成百上千时不可持续。模式级隔离：共享一个库的连接与缓冲资源，运维聚合方便，权限按模式切分仍可用，代价是资源争抢与"一个误操作波及全库"的风险半径。还有共享表加租户列的第三种：隔离最弱、成本最低，靠行级控制补隔离语义。三种形态对应三种租户规模与合规等级，选型的判断锚点是"租户要求独立恢复能力吗"——要求独立备份恢复的，库级几乎是唯一解。

本节要点回顾

• 层级链：集群（管理域）→ 实例 → 数据库 → 模式 → 对象，表空间横跨物理存储；
• OID 是硬通货：备份校验、主备对账认 oid 不认名字；
• 三组易混：管理域的集群不是主备的集群；库是隔离单元，模式是命名空间；实例不是单个进程；
• 三大机制词：WAL 保持久、Checkpoint 控恢复、MVCC 管并发，后续章节逐一拆开；
• 权限四层：库 CONNECT、模式 USAGE、表级、列级，少一层就报无权限。

术语立好了，下一节回到选型的最终问题：桌上摆着 PostgreSQL、MySQL 和商业国产库，openGauss 凭什么胜出？我们把五维对比摆开。