简介：《VASTDATA Vastbase G100 V2.2用户手册》面向数据库管理员、开发人员及信创项目技术人员，系统讲解基于openGauss开发的国产数据库Vastbase G100的使用方法，帮助读者快速建立从概念到实操的完整认知。资源包共1个PDF文件，约8.76MB，内容涵盖数据库逻辑结构图、数据查询请求处理过程、事务管理及相关概念，并详细说明连接数据库的多种方式（配置服务端远程连接、使用vsql连接、应用程序接口）、关闭数据库、创建和管理数据库、规划存储模型、列存数据压缩以及表空间管理等操作要点。手册目录层级清晰，从概述逐步深入到具体操作指导，便于按模块查阅与对照实践。目前已有198人学习，适合需要了解国产化数据库解决方案、开展信创数据库部署与日常管理工作的技术人员参考使用。

1. 拿到一份 700 多页的国产库手册，先别急着从头翻

信创项目里被问到“这个库到底怎么连、怎么建表、怎么迁”，手边只有一份 Vastbase G100 V2.2 用户手册，很多人第一反应是从第 1 页读到最后一页，结果读到第 3 章已经忘了第 2 章讲的事务隔离级别。这份手册的真实用法不是通读，而是当字典查：先立住逻辑结构、连接方式、存储模型这三根柱子，剩下的建表、分区、权限、备份按需翻。它面向的是正在做信创数据库选型和落地的从业者——已经会用某一种关系型库，现在要在一个基于 openGauss 路线的国产库上把活干完。手册覆盖了从 vsql 连接、JDBC/ODBC 开发、表空间与分区表管理，到客户端认证、SSL、三权分立的完整链路，够你把一个业务库从零搭到能跑。下面按我实际拆这份文档的顺序讲，哪些章节值得精读、哪些命令能直接抄、哪些参数改错会翻车。

2. 先把逻辑结构和连接链路立住：vsql、JDBC、ODBC 三条路怎么选

2.1 逻辑结构决定了你后面所有操作的边界

手册第 2 章给的数据库逻辑结构图，本质上是把“实例—数据库—schema—表/索引/视图”这四层摊开给你看。Vastbase G100 沿的是 openGauss 那套多数据库实例模型：一个实例下可以挂多个数据库，数据库之间默认不互通，跨库访问要么走 schema 映射要么走外部表。这一点和某些单库多 schema 的库不一样，新手最容易在这里翻车——以为建了库就能直接select另一库的表，结果报对象不存在。

我一般会先确认三件事再动手：当前连的是哪个库（select current_database();）、默认 schema 是不是public、以及search_path里挂了哪些 schema。手册 3.11.1 讲 schema 管理时提到 schema 是表的命名空间，权限也是按 schema 授的，所以规划阶段就要把“业务 schema / 公共 schema / 临时 schema”分开，别全塞 public。数据查询请求的处理过程那一节讲的是解析、优化、执行三段，实际排障时有用：一条 SQL 慢，先看是解析阶段被规则改写拖住，还是执行阶段扫描量太大，手册里对执行计划的入口有交代，配合explain能定位。

2.2 三条连接路径的适用场景和最小可用配置

手册 3.2 把连接分成服务端远程连接配置、vsql 命令行、应用程序接口三类。选型上我的经验是：运维和排障走 vsql，Java 业务走 JDBC，C/C++ 或老系统对接走 ODBC 或 libpq。三条路的服务端前置条件是一样的——pg_hba.conf里放行客户端网段、postgresql.conf里listen_addresses不能只绑 localhost。手册 5.1.1 配置客户端接入认证那节把 hba 的认证方式列全了，trust、md5、sha256、cert 都有，生产环境别用 trust，这是血泪经验。

vsql 连接的最小命令长这样，参数含义我标在注释里：

# -h 服务端地址，-p 端口默认 5432 视部署而定，-d 目标库，-U 用户名 vsql -h 192.168.10.21 -p 5432 -d business_db -U app_user -W # -W 表示交互式输入密码，避免密码进 shell history

连上之后先跑一遍环境自检，确认字符集、时区、版本对得上：

-- 确认版本与字符集，迁移前必查 select version(); show server_encoding; show timezone; -- 确认当前 search_path，避免建表建错 schema show search_path;

JDBC 这边手册 4.2 给了驱动版本与 JDK 兼容性对照，加载驱动的写法是标准的Class.forName，连接串里currentSchema参数建议显式指定，别依赖默认。连接池那节提到要配prepareThreshold和defaultRowFetchSize，前者影响预编译语句缓存，后者影响大结果集的分批拉取，两个都不配的话，批量查询容易把客户端内存顶爆。ODBC 的坑在驱动替换：手册 4.3.2 要求先装 unixODBC 再替换客户端驱动，odbcinst.ini和odbc.ini两个文件分别管驱动和数据源，配完用isql -v 数据源名测通再上业务，别跳过这步直接联调。

2.3 关库和参数配置：别在业务高峰动

手册 3.3 给了两种关库方式，SQL 语句关和vb_ctl工具关。区别在于vb_ctl stop支持-m模式参数：smart 等现有连接断完、fast 回滚未提交事务后关、immediate 直接杀。生产上我一般用 fast，smart 在长连接场景下可能等半小时都关不掉。3.10 配置数据库参数那节强调部分参数要重启生效、部分 reload 即可，改之前先用show 参数名看当前值，改完用select * from pg_settings where name='xxx';确认pending_restart字段，别改完以为生效了其实还挂在待重启状态。

3. 建表、分区、压缩：存储模型选错，后面全是补丁

3.1 行存还是列存，先看查询模式再定

手册 3.5 规划存储模型这节是整份文档里最该精读的部分之一。行存适合 OLTP 那种按行增删改、点查多的场景；列存适合宽表聚合、大批量扫描的分析场景。Vastbase G100 的列存表在 3.6 还专门讲了压缩，列存加压缩对历史数据归档类业务很划算，但列存表的更新代价高，频繁 update 的表别选列存，这是选型阶段就要定死的，后期改存储模型等于重建表加迁数据。

建表时几个关键子句我一般会显式写全，不靠默认值：

-- 行存表，指定填充因子和表空间，避免默认值带来的意外 create table t_order ( order_id bigint primary key, customer_id bigint not null, amount numeric(18,2), create_time timestamp default now() ) with (fillfactor=80) tablespace tbs_business; -- 列存表，开启压缩，适合分析型宽表 create table t_order_archive ( order_id bigint, customer_id bigint, amount numeric(18,2), create_time timestamp ) with (orientation=column, compression=low) tablespace tbs_archive;

fillfactor=80是给行存表留更新空间，页内预留 20% 减少行迁移；orientation=column切列存，compression取 low/middle/high，压缩比越高 CPU 开销越大，归档表用 low 到 middle 就够。表空间要先建好再引用，手册 3.7 的表空间管理里提到表空间对应物理目录，建之前确认目录权限归数据库运行用户，否则建表直接报权限错。

3.2 分区表：default 分区是兜底不是万能

手册 3.8.8 分区表那节篇幅不小，支持 range、list、hash 几种，3.8.8.1 还专门讲了 default 分区。default 分区的作用是接住所有不落在已定义分区里的数据，好处是不会因为插入越界值报错，坏处是数据悄悄进了兜底分区你都不知道。我的做法是：default 分区建上，但配一个定时任务查 default 分区的行数，超过阈值就告警，然后补建对应分区再把数据挪过去。

-- 按范围分区，带 default 兜底 create table t_log ( log_id bigint, log_time timestamp not null, content text ) partition by range (log_time) ( partition p202401 values less than ('2024-02-01'), partition p202402 values less than ('2024-03-01'), partition p_default values less than (maxvalue) ); -- 查兜底分区积压情况，定期跑 select count(*) from t_log partition (p_default);

分区键的选择有个硬约束：分区键必须是主键或唯一约束的一部分，否则建表直接失败。很多人从别的库迁过来，习惯用自增 id 做主键、用时间做分区键，到这儿就卡住，解决办法是把分区键并进主键，或者放弃该表的主键约束改用唯一索引。手册里对分区表的局部索引和全局索引也有区分，分区表上的唯一索引如果没带分区键，只能是全局索引，维护代价更高，这点在 3.11.2 索引管理里能对上。

3.3 闪回表和全局临时表：两个容易被忽略的后悔药

手册 3.8.6 闪回表和 3.8.7 全局临时表，是实际运维里救过命的两个特性。闪回表依赖表的删除记录保留，误删数据后在一定时间窗口内能把表恢复到删除前状态，前提是回收站机制没被清。全局临时表的会话隔离性要搞清楚：on commit preserve rows和on commit delete rows两种行为差别很大，前者会话内一直保留、后者提交即清，用错会导致“数据莫名其妙没了”或者“临时表越积越大”。

-- 全局临时表，会话级保留，适合中间结果集 create global temporary table tmp_calc ( id bigint, val numeric ) on commit preserve rows; -- 闪回误删的表（需回收站内对象仍存在） flashback table t_order to before drop;

闪回不是万能的，表被 drop 之后如果回收站被清或者过了保留期，就只能走备份恢复。所以 3.11.6 的vb_basebackup备份和 3.11.7 的表空间备份该配还得配，闪回当第一道防线，备份当最后一道。

4. 权限、认证与 SSL：安全章节不是选读，是上线前必过

4.1 三权分立和行级访问控制怎么落地

手册 5.2 管理用户及权限这章，5.2.3 三权分立是信创场景里经常被审计点名的一项：把系统管理员、安全管理员、审计管理员分开，互相制约。落地时不是建三个用户就完事，要确认审计功能真的开了、审计日志有独立存放路径、安全管理员不能自己改自己的权限。5.2.8 行级访问控制（RLS）适合多租户或者按部门隔离数据的场景，策略写在表上，查询时自动加过滤条件，比在应用层拼 where 靠谱，但要注意 RLS 对性能有影响，策略表达式别写太复杂。

-- 开启行级访问控制并建策略：只允许看到本部门数据 alter table t_order enable row level security; create policy p_dept on t_order using (dept_id = current_setting('app.dept_id')::bigint); -- 会话里设置当前部门上下文 set app.dept_id = '1001';

current_setting读的是会话变量，应用连接建立后先set再查，这个模式在连接池场景下要小心：连接复用时会话变量可能残留，最好在每次借出连接时重置。

4.2 SSL 连接和连接数监控

手册 5.1.3 的 SSL 证书管理和 5.1.4 用 SSL 做安全 TCP/IP 连接，是跨网段部署时的必配项。证书生成那节给了自签流程，生产环境建议用内部 CA 签发，服务端配ssl=on、ssl_cert_file、ssl_key_file，客户端 JDBC 连接串加ssl=true&sslmode=verify-full，ODBC 在数据源里勾 SSL 选项。配完一定要用vsql "sslmode=verify-full ..."验证一次，别只看配置文件以为成了。

连接数监控在 5.1.5，核心是查pg_stat_activity：

-- 按用户和状态统计连接数，定位连接泄漏 select usename, state, count(*) from pg_stat_activity group by usename, state order by count(*) desc; -- 查长时间 idle in transaction 的连接，这类最占资源 select pid, usename, state, now()-state_change as idle_time from pg_stat_activity where state = 'idle in transaction' order by idle_time desc;

idle in transaction是连接池配置不当的典型症状，事务开了没提交、连接又被还回池里，时间一长把连接数占满。解决办法是连接池配maxLifetime和事务超时，数据库侧配idle_in_transaction_session_timeout兜底。

5. 避坑与排查：这五条是我在真实环境里踩出来的

5.1 远程连不上，先查 hba 再查防火墙

现象：本地 vsql 能连，另一台机器连报“no pg_hba.conf entry”。原因：pg_hba.conf只放行了 127.0.0.1，没加客户端网段。解决：在 hba 里加一行host all all 192.168.10.0/24 sha256，然后vb_ctl reload让配置生效，不用重启。改完用vsql -h 目标IP从客户端侧验证，别在服务端本机测，本机走的是 local 规则。

5.2 建表报“tablespace does not exist”，目录权限是根因

现象：create table ... tablespace tbs_xxx报表空间不存在或权限拒绝。原因：表空间目录建了但属主不是数据库运行用户，或者建表空间时路径写错。解决：先\db列出已有表空间确认名字，再检查目录ls -ld属主，用create tablespace tbs_xxx location '/data/tbs_xxx';重建，路径必须是绝对路径且目录为空。

5.3 JDBC 批量插入慢得离谱，reWriteBatchedInserts没开

现象：同样的批量 insert，别的库几秒跑完，这边几分钟。原因：驱动默认把批量语句逐条发，没合并成多值插入。解决：连接串加reWriteBatchedInserts=true，配合prepareThreshold=5让驱动在第五次执行后转预编译。改完用explain看执行计划确认是批量形态，别只看耗时下降就以为对了。

5.4 分区表插入报“no partition for tuple”，default 分区没建或没生效

现象：插入一条时间超出已定义分区范围的数据，直接报错。原因：建分区表时没加 default 分区，或者 default 分区建了但maxvalue写法不对。解决：补建partition p_default values less than (maxvalue)，注意 maxvalue 是关键字不是字符串。补建后历史越界数据不会自动迁移，要手动insert into ... select挪过去再删原数据。

5.5 改完参数没生效，pending_restart是黑匣子

现象：alter system set改了参数，show看还是旧值。原因：该参数属于 postmaster 级别，必须重启才生效，reload 只对 sighup 级别参数有效。解决：改完查select name, setting, pending_restart from pg_settings where name='参数名';，pending_restart为 t 就说明要重启，挑维护窗口执行vb_ctl restart，别在业务高峰赌运气。

6. 进阶：把手册当查询字典，配一套自己的验证脚本

手册 700 多页，真正高频用到的其实集中在几个入口：连接与认证（3.2、5.1）、存储与分区（3.5、3.8）、权限（5.2）、备份（3.11.6）。我的习惯是给每个入口配一段可重复执行的验证 SQL，部署完新环境先跑一遍，比翻文档逐条核对快得多。下面这套自检脚本覆盖了版本、字符集、连接数、表空间、分区兜底、参数待重启六个维度，跑完输出一张体检表：

-- 环境体检：一次性输出关键状态 select 'version' as item, version() as val union all select 'encoding', current_setting('server_encoding') union all select 'connections', count(*)::text from pg_stat_activity union all select 'tablespaces', count(*)::text from pg_tablespace union all select 'pending_restart', count(*)::text from pg_settings where pending_restart union all select 'idle_in_txn', count(*)::text from pg_stat_activity where state = 'idle in transaction';

这段脚本的价值在于把分散在手册各章的检查点收拢成一次执行，新环境上线前跑一遍，pending_restart不为 0 就说明有参数改了没重启，idle_in_txn偏高就说明连接池配置有问题。配合前面 5.1 的 hba 检查、5.4 的 default 分区积压查询，基本能覆盖部署阶段八成以上的低级故障。

再往深一层，手册 4.2.9 连接池和 4.4 基于 libpq 开发这两节，适合做中间件或自研网关的团队精读。libpq 那套接口在国产化替代里经常被用来对接老 C 系统，手册给的连接参数和错误码处理是排障依据。JDBC 的ResultSet游标用法（4.2.6.2）在处理百万行导出时比一次性 fetch 稳得多，配fetchSize分批拉，内存曲线是平的而不是锯齿。

从那以后我每次接手一个新库环境，都强制先跑一遍这套体检脚本再谈业务迁移，翻车次数明显下来了。手册本身不会告诉你哪条参数在你这套部署里会咬人，但把它的章节入口和自检脚本绑在一起用，至少能把“改完没生效”“连不上”“分区越界”这几类问题挡在上线之前。希望帮到你。

本文还有配套的精品资源，点击获取