★ FEATURED ARTICLE 简介《VASTDATA Vastbase G100 V2.2用户手册》面向国产化数据库初学者、开发与运维人员服务于信创数据库选型了解、日常操作查询和基础使用学习。手册围绕 Vastbase G100 的整体概况展开先介绍数据库逻辑结构图、数据查询请求处理过程、管理事务与相关概念再延伸到连接数据库、配置服务端远程连接、使用 vsql 和应用程序接口、关闭数据库、创建和管理数据库、规划存储模型及表空间等操作目录层级清楚适合按模块检索也便于快速建立 Vastbase G100 的使用框架。压缩包仅含 1 个 PDF 文件大小约 8.76MB便于离线保存与随查随用文中还提醒 OCR 扫描可能存在个别字识别误差阅读时需结合上下文理解。已有 199 人学习可作为梳理国产数据库基础概念、熟悉常用操作路径和排查入门问题的参考资料。1. 拿到 Vastbase G100 V2.2 手册先别急着翻目录三类人能在里面找到什么信创数据库这四个字很多人是在选型会上第一次听到的真正落到手里第一件事是找一份能照着敲的手册。Vastbase G100 V2.2 的用户手册就是这种定位的东西它不讲故事讲的是一个基于 openGauss 路线演进的关系型数据库从逻辑结构、连接方式、建表建分区一路写到 JDBC/ODBC 接口和 SSL 认证。放进一套完整的数据库解决方案里它承担的是“底座怎么连、对象怎么建、权限怎么管”的那部分。适合两类人一类是刚接手这套 vastbase 数据库、要在一周内把环境和业务跑通的开发另一类是 DBA拿它当参数和权限策略的对照表。手册里那些目录层级其实就是排错时的检索路径。2. 从逻辑结构到查询链路前两章先建立三个模型很多人拿到 PDF 直接跳到第 3 章“从这里开始”结果敲到第五行就卡住因为不知道该在哪个库里建 schema、不知道该用哪个用户连。前两章看着像背景铺垫实际是把后面所有操作的坐标系先定下来。这三个模型没建立起来后面每一条命令都是盲敲库和实例的边界在哪、一条 SQL 进来之后被谁处理、事务的提交点落在哪。2.1 逻辑结构图决定了你的对象命名习惯手册 2.1 给的逻辑结构本质是一条自上而下的包含链数据库实例 → 数据库Database→ 模式Schema→ 表/索引/视图/序列 → 表空间Tablespace。这条链里有两个容易混的边界值得提前说清楚。第一个边界是实例与数据库。一个实例下可以挂多个数据库库与库之间默认不互通跨库访问要走外部表或者应用层拼装。所以规划阶段就要决定是按业务线分库还是单库多 schema。我一般建议单库多 schema理由是连接串只改一个参数就能切环境备份和权限也能按 schema 粒度收敛。第二个边界是 schema 与用户。这套库的默认行为是用户创建后拥有一个同名 schemasearch_path默认指向它。这就意味着如果你用 A 用户建了表再用 B 用户去查不写全限定名就会报“表不存在”。这不是 bug是权限和路径共同作用的结果。-- 建库时显式指定编码与兼容模式避免后期迁移时字符集返工 CREATE DATABASE appdb WITH ENCODING UTF8 DBCOMPATIBILITY A TEMPLATE template0; -- 建独立 schema不要图省事全塞进 public CREATE SCHEMA app_core; -- 把新 schema 放到搜索路径最前面只对当前会话生效 SET search_path TO app_core, public;DBCOMPATIBILITY是这套库比较关键的一个参数取值决定了对其他数据库语法的兼容程度A 通常对应 Oracle 风格、B 对应 MySQL 风格具体取值手册 3.4 有完整列表。建库之后再改这个参数代价很大属于典型的“后悔药没处买”的选项务必在第一次建库时定死。TEMPLATE template0的作用是拿一个干净模板起库避免把模板库里的对象带进来。SET search_path只影响当前会话断开重连就失效。要长期生效得用ALTER DATABASE appdb SET search_path TO app_core, public;或者写进用户的属性里。这一点在排查“为什么我这边能查到、同事那边查不到”时非常有用——大概率就是两个人的 search_path 不一样。2.2 一条查询请求进来之后经过了哪几层手册 2.2 描述的数据查询请求处理过程是后面所有性能问题的解释框架。简化成一条链客户端发起连接 → 监听进程接受并做认证 → 分配服务线程 → 语法解析 → 查询重写 → 优化器生成执行计划 → 执行器拉取数据 → 存储层读写。这条链上每一环都有对应的可观测点记住它们比记住参数名更有用环节出问题时的典型表现先看什么连接与认证连接超时、认证失败监听地址、认证配置文件、防火墙解析与重写语法报错、对象找不到search_path、对象是否存在优化器计划走错、全表扫描统计信息是否新鲜、执行计划执行器内存溢出、临时文件暴涨work_mem 类参数、排序量存储层IO 打满、写入放大行存/列存选型、压缩比优化器那一环是最容易被误判的。同一张表统计信息刚收集完和长期没收集执行计划可能从索引扫描变成顺序扫描差出几十倍。所以碰到“昨天还快、今天突然慢”第一反应不该是改参数而是看统计信息是不是过期了。这套库里有自动收集机制但批量导入大量数据之后自动收集往往跟不上手动跑一次 ANALYZE 是常规操作。2.3 事务的边界要写在代码里不能指望默认行为手册 2.3 讲管理事务核心是三件事显式开启、显式提交、异常回滚。默认情况下这套库是自动提交模式一条 INSERT 发过去就落盘了。这在交互式敲命令时很方便在批量写入时就是灾难——一万条 INSERT 就是一万次提交每次提交都要刷日志。-- 批量写入务必显式包事务把提交次数压到个位数 BEGIN; INSERT INTO app_core.tb_order (order_id, cust_id, amount) VALUES (1001, 2001, 99.50); INSERT INTO app_core.tb_order (order_id, cust_id, amount) VALUES (1002, 2002, 149.00); -- 中间可以做校验出错直接 ROLLBACK COMMIT;BEGIN到COMMIT之间的语句构成一个原子单元。要注意的是长事务问题一个事务开在那里几十分钟不提交会阻止回收机制清理旧版本数据表文件只涨不缩。这一条在手册里不会写得很重但实际运维中是最常见的“磁盘莫名满了”的成因之一。还有一个细节是保存点。复杂业务里如果只想回滚部分操作用SAVEPOINT sp1;打点出错时ROLLBACK TO sp1;整体事务还能继续。这个用法在批量导入部分失败的场景里很好使比整批重跑省时间。3. 连接、建库、建表把第 3 章拆成四步落地第 3 章是整本手册最厚的一章也是最容易读散的一章。它把连接、建库、存储模型、表空间、表、分区、系统表、参数全铺在一起顺序读会不断被打断。我的建议是按依赖关系重排先打通连接再定存储位置再建对象最后才是分区和压缩这类优化项。下面这四步就是按这个顺序来的。3.1 远程连接打不通先改这三处默认安装完之后服务端只监听本地回环地址认证配置里也只放行了本地连接。想让应用服务器连过来需要动两个文件加一次重载。第一步改监听地址。在数据目录下的postgresql.conf里找到listen_addresses# 只监听指定网卡比写 * 安全多网卡用逗号分隔 listen_addresses 192.168.10.11,127.0.0.1 # 端口按实际规划填默认实例端口不要和同机其他实例撞 port 5432第二步在pg_hba.conf里加放行条目注意顺序是从上往下匹配、命中即止# TYPE DATABASE USER ADDRESS METHOD host appdb appuser 192.168.10.0/24 sha256 host all all 127.0.0.1/32 trustMETHOD一列决定认证方式sha256是口令认证的常用取值trust表示免密——只应该出现在回环地址那一行放到业务网段上等于开门。ADDRESS支持 CIDR 写法网段划得越细越好别图省事写0.0.0.0/0。第三步重载配置。这套库提供了vb_ctl工具# reload 只重读配置不断连接改监听地址这类参数通常 reload 即可 vb_ctl reload -D /data/vastbase/data # 确认进程状态与端口监听 vb_ctl status -D /data/vastbase/data ss -lntp | grep 5432-D指向数据目录路径要和安装时一致否则工具会报找不到实例。改完还不通按这个顺序排查本机ss看端口有没有起来 → 从客户端telnet看网络层通不通 → 看pg_hba.conf里有没有更靠前的规则先命中了拒绝。第三条是最容易漏的因为规则是顺序匹配的前面一条host all all 0.0.0.0/0 reject会把后面的放行全部吃掉。3.2 用 vsql 建立第一条会话vsql是这套库自带的命令行客户端用法和主流数据库的 CLI 类似。连上去之后先做三件事看版本、看当前库、看当前用户。这三条信息在提工单和查文档时是必备上下文。# -h 主机 -p 端口 -d 库名 -U 用户名-W 强制提示输入口令而不是明文写在命令里 vsql -h 192.168.10.11 -p 5432 -d appdb -U appuser -W进入交互界面后-- 版本信息决定你能用哪些语法特性别凭印象写 SELECT version(); -- 确认自己连的是哪个库、哪个用户、search_path 是什么 SELECT current_database(), current_user, current_setting(search_path); -- 查看连接数排查“连接池被打满”时第一眼看这个 SELECT count(*) FROM pg_stat_activity;-W这个参数值得单独说。很多脚本里图方便把口令写进命令行结果是ps -ef一眼就能看到属于典型的安全隐患。要么用-W交互输入要么用环境变量配合.pgpass类的凭据文件权限设成 600。pg_stat_activity这张系统表在手册 3.9 有说明它能告诉你每个连接的来源地址、状态、正在执行的语句。线上出现“连接数满了但业务量不大”的情况八成是有连接泄漏看这张表里state长时间停留在 idle 的会话来自哪台机器基本就能定位到是哪个应用没关连接。关闭数据库有两条路径手册 3.3 分开写了SQL 方式和工具方式。日常维护我优先用工具方式因为可以控制模式——正常关闭会等待现有连接结束快速关闭直接断开立即关闭相当于断电只在万不得已时用。SQL 方式适合写在脚本里由应用侧触发但权限要收得很紧普通业务账号不应该有这个能力。3.3 建库、建表空间、建表的依赖顺序顺序错了会反复返工表空间没建就先建表表会落到默认位置后期迁过去要重建索引。正确顺序是表空间 → 数据库 → schema → 表。-- 表空间指向一个独立的挂载点路径写法按手册 3.7 的相对位置语法 CREATE TABLESPACE tsp_app RELATIVE LOCATION tablespace/tsp_app; -- 建库时指定默认表空间避免用户忘了指定就落到系统盘 CREATE DATABASE appdb WITH ENCODING UTF8 TABLESPACE tsp_app; -- 大表单独放一个表空间方便按盘做备份和限流 CREATE TABLESPACE tsp_big RELATIVE LOCATION tablespace/tsp_big;RELATIVE LOCATION是相对数据目录的路径这一点和直接用绝对路径的数据库不一样容易踩。手册 3.7 明确给了这个语法但很多人按其他数据库的习惯写绝对路径直接报错。表空间的现实价值在于 IO 隔离和备份粒度。把写入量大的日志表和读多写少的维表分到不同表空间落到不同物理盘上互相不抢 IO。备份的时候也能按表空间分批做手册 3.11.7 专门讲了表空间级别的备份与恢复。建表这一步除了常规的字段和约束最需要提前决策的是存储模型。3.4 行存、列存与压缩选型错了后面全是补丁手册 3.5 规划存储模型、3.6 列存下的数据压缩这两节要连起来看。行存适合 OLTP按行读取单条增删改代价小点查快。列存适合 OLAP按列读取聚合扫描只读需要的列压缩比高但单条更新代价大。-- 明细流水表写入密集、点查多用行存 CREATE TABLE app_core.tb_order ( order_id bigint NOT NULL, cust_id bigint NOT NULL, amount numeric(12,2), create_time timestamp DEFAULT now(), CONSTRAINT pk_tb_order PRIMARY KEY (order_id) ) WITH (ORIENTATION ROW, STORAGE_TYPE USTORE); -- 统计分析表一次写入、反复聚合用列存并开压缩 CREATE TABLE app_core.tb_order_stat ( stat_date date, cust_id bigint, total_amt numeric(18,2), order_cnt bigint ) WITH (ORIENTATION COLUMN, COMPRESSION HIGH);ORIENTATION有两个取值ROW和COLUMN建表时定死后期改要整表重写。COMPRESSION只对列存有意义HIGH压缩比更高但写入 CPU 开销更大日志类冷数据可以开到高档位需要频繁扫的热数据用中档更均衡。STORAGE_TYPE USTORE是行存的存储引擎选项手册 3.5 有对照表不同引擎在更新密集场景下表现差别明显。这里有一条血泪经验列存表不要用来做单条 INSERT 的业务表。列存的写放大在批量场景下才摊得平一条一条插进去性能会比行存差一个数量级而且会产生大量小文件。如果业务确实需要“明细行存 分析列存”标准做法是行存承接交易定时把数据批量灌进列存做分析两套表各司其职。3.5 分区表与 default 分区边界值是最容易错的地方手册 3.8.8 讲分区表3.8.8.1 特别提到支持 default 分区。分区表的价值在于两件事查询裁剪和分区级维护。前者让优化器只扫相关分区后者让删历史数据变成 DROP PARTITION 而不是 DELETE。-- 按月做范围分区最后一个分区兜底防止新数据插不进去 CREATE TABLE app_core.tb_log ( log_id bigint, log_date date NOT NULL, content text ) PARTITION BY RANGE (log_date) ( PARTITION p_202401 VALUES LESS THAN (2024-02-01), PARTITION p_202402 VALUES LESS THAN (2024-03-01), PARTITION p_default VALUES LESS THAN (MAXVALUE) );VALUES LESS THAN是开区间不含右端点。LESS THAN (2024-02-01)表示所有小于 2 月 1 日的日期2 月 1 日当天会落到下一个分区。这个语义错一次整月的报表数据就会错位而且因为不报错很难发现。MAXVALUE兜底分区是保命的。没有它超出范围的插入会直接报错业务侧半夜告警。但如果加了兜底分区却不做数据搬移时间一长兜底分区会变成最大的那一个查询裁剪形同虚设。常规做法是留一个定时任务定期检查兜底分区里有没有数据有就 ALTER TABLE 拆分出新区间并把数据迁过去。4. 应用侧接入JDBC、ODBC、libpq 三条链路的参数怎么写手册第 4 章占了很大篇幅JDBC、ODBC、libpq 三条链路分开写很多内容是重复的——连接、执行、游标、大数据类型三条链路各写一遍。读的时候可以只精读一条另外两条对照差异点。这一节按“选哪条、怎么配、哪里会卡”的顺序展开。4.1 选型先看你的运行时在哪一侧Java 应用走 JDBC这是主流。C/C 或者需要嵌到已有 native 进程里的走 libpq它是最薄的一层没有额外依赖。ODBC 更多出现在 BI 工具、报表平台、以及一些历史系统里链路最长配置项也最多。三条链路的共性是都要解决四件事驱动放在哪、连接串怎么写、认证怎么过、结果集怎么取。差异在于前三件事的具体形态。JDBC 靠 jar 包和 classpathODBC 靠驱动管理器加数据源配置libpq 靠动态库加连接字符串。手册 4.2.2 专门讲了 JDBC 与 JDK 的兼容性这一节不要跳过。不同驱动版本对 JDK 的最低要求不一样用错了表现是运行时报类找不到或者方法不存在而不是编译期报错排查起来很费时间。4.2 JDBC类路径、驱动加载与连接串JDBC 的配置分三步把驱动 jar 放进类路径、代码里加载驱动类、拼连接串。# 方式一应用启动时用 -cp 把驱动带进去适合独立 jar 部署 java -cp app.jar:/opt/vastbase/jdbc/vastbase-jdbc.jar com.example.Main # 方式二把 jar 丢进 Web 容器或构建工具的依赖目录由容器统一加载 # 具体目录按容器类型定放错位置的表现就是 ClassNotFoundException代码侧// 驱动类名以手册 4.2.4 示例中的写法为准不同驱动包版本包名可能有差异 Class.forName(org.vastbase.Driver); // ssltrue 表示启用加密链路sslmode 决定是否校验服务端证书 String url jdbc:vastbase://192.168.10.11:5432/appdb ?ssltruesslmodeverify-ca connectTimeout10socketTimeout60; Connection conn DriverManager.getConnection(url, appuser, ******);sslmode有几个档位disable不加密、require加密但不校验证书、verify-ca校验证书链、verify-full连主机名一起校验。生产环境至少用verify-ca只写require相当于防了窃听没防中间人。connectTimeout和socketTimeout这两个参数建议显式写。默认值在跨机房场景下可能太长导致故障时连接池里全是挂住的连接。设成 10 秒和 60 秒是个比较稳妥的起点具体按业务的 RT 上限调。手册 4.2.9 讲连接池。这里有个常见误区以为换了连接池就能解决性能问题。实际上连接池解决的是“连接建立开销”不解决慢 SQL。池子大小也不是越大越好连接数超过数据库的并发处理能力之后多出来的连接只是在排队反而增加上下文切换。经验值是按 CPU 核数的两到四倍来估再用压测校准。4.3 游标与结果集大结果集不要一次拉完手册 4.2.6.2 专门写了“使用游标获取结果”。这一节的现实意义在于一次SELECT返回几十万行驱动默认会把结果全部读进内存堆直接爆掉。// 关闭自动提交是游标生效的前提否则驱动会一次性取完 conn.setAutoCommit(false); Statement stmt conn.createStatement( ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY); stmt.setFetchSize(1000); ResultSet rs stmt.executeQuery(SELECT * FROM app_core.tb_log); while (rs.next()) { // 逐批处理内存占用稳定在 fetchSize 量级 } conn.commit();setFetchSize(1000)是关键它告诉驱动每次从服务端取多少行。取太小网络往返次数多取太大内存压不住1000 左右是个常用起点。setAutoCommit(false)不能省自动提交模式下游标会被提前物化fetchSize形同虚设。存储过程返回结果集也是同理手册 4.2.7.1 讲了获取结果集的写法核心是把CallableStatement的getResultSet()和游标配合用而不是一次性getObject()。大数据类型手册 4.2.8分二进制和字符串两类处理方式不同。二进制走流式读写避免整个 blob 进内存大字符串要注意字符集转换带来的额外内存放大。4.4 ODBC 与 libpq配置链路更长顺序不能乱ODBC 的配置步骤比 JDBC 多得多手册 4.3.2 拆成了六步装数据库或客户端、装 unixODBC、替换客户端驱动、配数据源、配环境变量、测数据源。这六步的顺序不能颠倒尤其是“替换客户端驱动程序”这一步本质是把驱动管理器指向这套库自己的.so文件指错了后面全白搭。# 数据源配置文件示例路径按 unixODBC 的实际安装位置 [vastbase_appdb] Description Vastbase G100 appdb Driver /opt/vastbase/odbc/lib/vbodbc.so Servername 192.168.10.11 Port 5432 Database appdb Username appuser Password ******配完之后必须用isql实测一次不要跳过这步直接上应用。isql -v vastbase_appdb能连上说明驱动、路径、口令全都对连不上时它会打印 SQLSTATE 错误码比应用里报的一行“连接失败”有用得多。libpq 是最薄的一层手册 4.4 给了最小示例。它没有驱动管理器直接链接动态库连接字符串用 keyvalue 形式拼// 连接字符串里的每一项都对应一个环境变量名也可以走环境变量 PGconn *conn PQconnectdb( host192.168.10.11 port5432 dbnameappdb userappuser password****** connect_timeout10); if (PQstatus(conn) ! CONNECTION_OK) { // PQerrorMessage 返回的是服务端原文排错时比自造错误信息有用 fprintf(stderr, connect failed: %s, PQerrorMessage(conn)); PQfinish(conn); return -1; }PQerrorMessage一定要打出来。很多人包装了一层之后把这条信息丢了排查时只能看到“连接失败”四个字等于把黑匣子扔了。5. 五个高频翻车点排查从连不上到权限报错手册是“正确的路径”实际干活时遇到的多半是路径之外的岔子。下面五条按出现频率排每条按现象、原因、解决写能对号入座的基本上十分钟内能收敛。5.1 远程连接被拒三处配置任意一处没改都会这样现象客户端报连接超时或者“no pg_hba.conf entry for host”。原因三种可能。监听地址还是默认的回环地址认证配置里没有对应的放行条目服务器防火墙没开端口。还有一种隐蔽的认证配置里有条目但被前面一条更宽的规则先命中了。解决按顺序验证。本机ss -lntp | grep 端口看监听是否生效没有就是listen_addresses没改或者没重载有监听但远端不通从客户端 telnet 测网络网络通还报认证错就看pg_hba.conf的规则顺序把具体网段的放行条目放到宽规则前面。改完统一vb_ctl reload不要 restart避免影响现有连接。5.2 列存表批量写入慢得离谱现象建了列存表业务按单条 INSERT 往里写TPS 只有行存表的几分之一磁盘上还冒出一堆小文件。原因列存的写入模型是批式组织单条写入要反复打开关闭列文件。手册 3.6 讲压缩时提到列存按列组织数据但没强调写入模式。选型错位是根因。解决短期改成攒批写入每批几千行用一条多值 INSERT 或者 COPY 导入中期把表改成行存承接交易另建列存表做分析长期在应用层做读写分离。判断标准很简单如果这张表的写入以单条为主、查询以点查为主就不该用列存。5.3 分区表数据全落进兜底分区现象分区表建好了查询还是全表扫一看执行计划把所有分区都扫了一遍再看数据90% 都在p_default里。原因两个可能。一是边界值算错LESS THAN是开区间日期差一天就会整体错位二是新分区没提前建数据全部由兜底分区接住。解决先用系统表确认每个分区的实际行数找出异常大的那个再核对分区边界定义和业务的时间口径是否一致尤其是时区问题——存的是 UTC 时间、边界按本地时间写必然错位。新分区用定时任务提前一个月建建完把兜底分区里对应区间的数据迁过去。手册 3.8.8 对分区维护有说明DDL 的操作窗口建议放在业务低峰。5.4 开启 SSL 后 JDBC 握手失败现象不带 ssl 参数能连加上sslmodeverify-ca就报证书校验失败。原因verify-ca要求客户端能验证服务端证书链。客户端信任库truststore里没有导入签发服务端证书的根证书或者证书的 CN/SAN 和连接串里的主机名对不上用verify-full时尤其明显。解决先确认服务端证书链完整手册 5.1.3 给了证书生成流程根证书、服务端证书、私钥三件套要对得上再把根证书导进客户端的信任库Java 侧用keytool -importcert重启应用最后核对连接串里的主机名要么写证书里的名字要么换verify-ca只校验证书链不校验主机名。调试阶段可以临时降到require确认链路本身通不通但别把这个配置带上线。5.5 开了三权分立之后管理员“没权限”现象原来能建用户、能改配置的账号开了三权分立之后操作被拒。原因手册 5.2.3 讲的三权分立是把传统的一个超级管理员拆成安全管理、审计管理、数据管理三个角色各自职责隔离。原来的管理员账号只保留其中一部分权限这是设计意图不是缺陷。解决先明确当前操作属于哪一类——建用户和授权归安全管理查审计日志归审计管理业务对象的增删改归数据管理。然后用对应角色的账号执行或者由安全管理员给业务账号单独授权。这里不要图省事把权限再合并回去三权分立一旦关掉审计链路就断了。顺带说一个相关的坑schema 建了但没授权业务账号查表报“对象不存在”。原因是 search_path 里没这个 schema或者有 schema 但没 USAGE 权限。手册 5.2.6 讲 schema 权限GRANT USAGE ON SCHEMA和GRANT SELECT ON TABLE是两步缺一不可。6. 把手册当字典查参数定位、执行计划验证与备份前的最后一道检查手册 700 多页从头读到尾不现实也没必要。真正高效的用法是把它当字典遇到具体问题时按目录定位到对应章节只读那一节。这一章讲三个我反复用的检索路径以及一个每次上线前都会走的验证动作。6.1 参数改动的三个来源优先级别搞反参数这东西在不同地方设置会有不同的生效范围优先级从高到低大致是会话级SET→ 用户级ALTER USER ... SET→ 数据库级ALTER DATABASE ... SET→ 实例级配置文件。会话级最灵活但只影响当前连接配置文件影响全局但需要重载。作用域命令形式生效时机典型用途会话SET param value;立即仅当前会话临时调大排序内存跑一条大查询用户ALTER USER u SET param value;该用户下次连接给批处理账号单独放宽资源数据库ALTER DATABASE d SET param value;该库下次连接按库隔离资源配额实例编辑配置文件 reloadreload 后对新会话生效全局内存、连接数上限排查“参数改了没生效”时先用SHOW 参数名;看当前会话实际拿到的值再逐层往上找是谁覆盖了谁。手册 3.10 有参数配置的完整说明配合系统表能看到每个参数的当前值和来源。6.2 用执行计划验证假设而不是靠猜判断一条 SQL 慢在哪唯一可靠的办法是看执行计划。习惯是先看有没有全表扫描再看扫描的行数和实际返回行数差多少。差得大说明统计信息不准先 ANALYZE 再看。-- 只看计划不真正执行避免在线上跑重查询 EXPLAIN SELECT cust_id, sum(amount) FROM app_core.tb_order WHERE create_time 2024-01-01 GROUP BY cust_id; -- 需要真实耗时和实际行数时才加 analyze线上慎用 EXPLAIN ANALYZE SELECT ...;看计划时重点看三处扫描方式顺序扫描还是索引扫描、估算行数与实际行数的偏差、有没有落到临时文件。第三项出现说明排序或哈希的内存不够这时候调work_mem才有意义。反过来如果计划本身就走错了索引调内存纯属浪费。6.3 备份表空间之前先确认这两件事手册 3.11.6 和 3.11.7 讲了vb_basebackup的 tar 格式备份和表空间备份。表空间备份比整库备份多一层依赖备份时必须知道每个表空间对应的物理路径恢复时这些路径要能对上。# 备份前先把表空间与路径的对应关系导出来恢复时照这个表建目录 vsql -h 192.168.10.11 -p 5432 -d appdb -U appuser -W \ -c SELECT spcname, pg_tablespace_location(oid) FROM pg_tablespace; # tar 格式备份-D 指定目标目录-t 指定表空间名按实际工具参数为准 vb_basebackup -D /backup/base_202403 -h 192.168.10.11 -p 5432 -t tsp_app -F t第一件事是路径清单。恢复到另一台机器上如果只恢复了数据目录没建表空间目录启动会直接失败。第二件事是备份期间的数据一致性——vb_basebackup依赖 WAL 保证一致性备份期间不要做删表空间的操作否则备份出来的清单和实际数据对不上。我一般的做法是把路径清单和备份文件放在同一个目录恢复脚本里先读清单建目录再解包。这个习惯来自一次深夜恢复备份文件在路径没记靠翻安装记录猜了半小时。从那以后我每次做表空间级备份都把路径清单和备份文件捆在一起恢复脚本里强制走一遍校验才允许继续。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
