简介：这份《数据库系统原理实验》报告文档面向计算机科学与技术、软件工程等专业学生及数据库入门学习者，围绕 openGauss 环境下的课程实验展开，可用于巩固数据库理论、完成实验报告撰写与操作复盘。全文按实验一至实验九组织，覆盖认识 DBMS 与 gsql 工具、创建数据库表及索引、交互式 SQL 查询更新、视图抽象与查询优化、完整性控制、权限与安全性控制、事务并发及锁机制、备份恢复和 JDBC 编程连接等内容，并记录实验目的、操作过程、问题更正与结果分析。资源包共 1 个 docx 文件，约 3.23MB，正文含目录、前言、实验步骤与结果分析，并说明截图、图题及表格排版要求，便于按章节查阅。已有 1527 人学习，适合需要对照 openGauss 安装连接、用户与数据库创建、SQL 命令使用、权限分配和事务处理等环节，快速定位实验报告应包含的步骤与材料，也可作为课程报告内容组织的参考。

1. 一份实验报告卡在第一步：库起不来，九个实验全是空的

上周又有人拿着一份《数据库系统原理实验》报告来找我，实验一到实验九写得满满当当，从认识 DBMS 到 JDBC 连接数据库，唯独截图里没有一条能跑通的 SQL。问题不在 SQL 写得对不对，而在装库这一步就翻车了：解压完安装包，敲gs_install报互信失败，折腾两小时后改成了「先装 openEuler 再装 openGauss」这条最老实也最费事的路线才走通。这套环境在计算机类、软件工程专业里几乎是标配，实验报告要求手写内容加电子截图，装不好连第一张图都拍不出来。这篇记录的就是我把这台单机 openGauss 从零装到能用 gsql 连上的全过程，包含系统预置、安装参数、建库建表顺序和几个把我卡到凌晨的坑。

2. 装之前把环境定死：openEuler 虚机、内存和 26000 端口

装数据库这件事，最贵的不是安装本身，是装到一半发现内存不够、主机名没配、端口被占，然后推倒重来。所以这一章不讲 openGauss，只讲把它要住的那间房先收拾干净。

2.1 三种安装路径的取舍：为什么我选「先装 openEuler 再装库」

实验指导里给了三条路：云上直接开实例、虚拟机一键部署脚本、虚拟机装 openEuler 之后再手动装 openGauss。三条路都能得到同一个能连的数据库，但对做实验报告的人来说，价值完全不同。

云上开实例最快，十分钟就能连上，代价是你什么都没看见。它把安装过程的参数、目录、用户全部藏起来了，报告里「实验一 认识 DBMS 系统」要求写的安装模式对比、启动方式、连接方式，你只能照着文档抄，截图也只有一张连接成功的终端。

一键部署脚本稍微好一点，命令行跑完就有一个集群。但它把gs_preinstall、gs_install、集群配置文件这些环节包成了黑匣子，一旦失败，输出里只剩几行 log 路径，新手根本不知道从哪儿看起。

我一般推荐第三条：先在虚拟机里装一个干净的 openEuler，再手动装 openGauss。理由是后面八个实验都要在这个库上做，只要环境是你自己一步步搭起来的，出问题时你知道改哪个文件；更实际的一点是，实验报告要求「说明实验过程中遇到的问题，如何更正」，你亲手踩过的坑才有东西可写。

提示：三条路选一条走完就行，别中途切换。我在一台机器上混用过一键脚本和手动安装，残留的 omm 用户和旧数据目录会让后面的gs_preinstall报一堆莫名其妙的权限错误。

2.2 虚机规格：内存、swap、磁盘三件必须先定

openGauss 单机对硬件不算苛刻，但也不是随便给 1G 内存就能跑。安装前gs_check会做环境检查，内存、swap、磁盘空间不达标会直接中断。下面这张表是我常用的规格，左边是最低线，右边是我实际给实验环境配的值：

磁盘这块有个血泪经验：很多人把/opt和根分区放一起，装完数据库再灌数据、做备份恢复实验，/一满，数据库直接起不来，报错还特别含糊。条件允许就把/opt单独挂一块盘。

系统装完之后，第一件事是把主机名和 hosts 定下来，因为后续的集群配置文件里要用节点名，gs_preinstall会拿这个名字做 ssh 互信：

# 固定主机名，重启后不变 hostnamectl set-hostname node1 # 写入 hosts，IP 换成你自己虚机的私网地址 cat >> /etc/hosts <<'EOF' 192.168.56.10 node1 EOF # 立刻验证，能 ping 通再往下走 ping -c 2 node1

主机名这一步看着琐碎，但它是后面 ssh 互信的地基。gs_preinstall会在 omm 用户下生成密钥对，然后ssh node1免密登录自己，如果node1解析不到，或者解析到了一个 DHCP 变过的地址，互信就会失败，报的错是Failed to establish trust relationship，第一次见很容易懵。

接着关掉两个拦路的东西：

# 关闭防火墙，openGauss 节点间和客户端连接都要用端口 systemctl stop firewalld systemctl disable firewalld # 关闭 SELinux，改成 disabled 后建议重启一次 setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config getenforce

防火墙和 SELinux 是典型的玄学问题来源：本地gsql能连、远程 JDBC 连不上，或者安装到一半某个端口探测失败，十有八九是这两个没关干净。实验环境里直接关掉，生产环境按需放行 26000 端口即可。

2.3 内核参数与资源限制：两份配置一次写对

openGauss 对信号量、共享内存、文件句柄有要求，这些参数不配，安装阶段可能侥幸通过，跑并发事务实验的时候就开始报错。常见做法是提前写进/etc/sysctl.conf：

cat >> /etc/sysctl.conf <<'EOF' # 网络相关，减少 TIME_WAIT 堆积 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_keepalive_time = 30 net.ipv4.tcp_max_tw_buckets = 10000 # 信号量与共享内存，数据库进程通信要用 kernel.sem = 250 32000 100 128 kernel.shmall = 1073741824 kernel.shmmax = 4398046511104 kernel.shmmni = 4096 fs.file-max = 6815744 EOF # 让配置立刻生效 sysctl -p

这几个参数里，kernel.sem是信号量数组，四个数字依次是每组的信号量数、系统级信号量总数、每次 semop 可操作数、信号量组数；kernel.shmmax是单个共享内存段的最大字节数，我习惯给到物理内存量级；fs.file-max是系统级文件句柄上限。改完用sysctl -p回显一遍，确认没写错行。

第二份是用户资源限制。注意这里可以先给omm写上，虽然用户还没建，但limits.conf是按用户名匹配的，等gs_preinstall建出这个用户，限制自动生效：

cat >> /etc/security/limits.conf <<'EOF' omm soft nofile 1000000 omm hard nofile 1000000 omm soft nproc 65536 omm hard nproc 65536 omm soft stack unlimited omm hard stack unlimited EOF

nofile是打开文件数，数据库每个连接、每个数据文件都占句柄，小了会报Too many open files；nproc是进程数；stack是栈大小，安装过程里有些步骤对栈有要求。写完最好重新登录一次终端让限制生效，用su - omm之后ulimit -n验证，看到 1000000 才算数。

3. openGauss 安装：从解压到 gs_om -t start

环境定死之后，安装本身其实只有三条主命令，真正花时间的是理解每一步在干什么，以及出错时知道去看哪个日志。

3.1 解压安装包与 cluster_config.xml 的写法

把安装包传到/opt/software/openGauss下。企业版的 all 包里套着一个 om 包，om 包才是真正提供gs_preinstall、gs_install、gs_om这些工具的东西，所以两层都要解：

# 统一放安装介质，权限给足 mkdir -p /opt/software/openGauss cd /opt/software/openGauss # 版本号按官方发布页选同架构的 all 包，x86 和 aarch64 别拿错 tar -zxvf openGauss-<版本号>-openEuler-64bit-all.tar.gz tar -zxvf openGauss-<版本号>-openEuler-64bit-om.tar.gz # 解压后应该能看到 script 目录和几个 xml 模板 ls -l

解压出来的script目录很关键，gs_preinstall、gs_install这两个可执行文件都在里面，同时还有cluster_config.xml的模板。单机部署可以直接在模板基础上改，我一般自己写一份干净的：

<?xml version="1.0" encoding="UTF-8"?> <ROOT> <CLUSTER> <PARAM name="clusterName" value="db_cluster"/> <PARAM name="nodeNames" value="node1"/> <PARAM name="gaussdbAppPath" value="/opt/gaussdb/app"/> <PARAM name="gaussdbLogPath" value="/var/log/gaussdb"/> <PARAM name="tmpMppdbPath" value="/opt/gaussdb/tmp"/> <PARAM name="gaussdbToolPath" value="/opt/gaussdb/om"/> <PARAM name="corePath" value="/opt/gaussdb/corefile"/> <PARAM name="backIp1s" value="192.168.56.10"/> </CLUSTER> <DEVICELIST> <DEVICE sn="node1"> <PARAM name="name" value="node1"/> <PARAM name="azName" value="AZ1"/> <PARAM name="azPriority" value="1"/> <PARAM name="backIp1" value="192.168.56.10"/> <PARAM name="sshIp1" value="192.168.56.10"/> </DEVICE> </DEVICELIST> </ROOT>

这份 xml 里每一项都不是随便填的，重点看这几个：

• clusterName：集群名，单机也必须有，后面gs_om -t status显示的实例名跟它有关。
• nodeNames：节点名，必须和hostname输出完全一致，包括大小写。
• gaussdbAppPath：程序安装目录，空间要给够，我放在/opt下。
• gaussdbLogPath：日志目录，这个路径以后会天天用，出问题第一时间来这里翻。
• corePath：core dump 目录，很多人不填，出问题时连崩溃现场都没留下，后悔药都没得吃。
• backIp1s和backIp1：节点 IP，必须和/etc/hosts里配的一致。

注意：xml 里所有目录都必须存在且属主正确，或者由安装程序自动创建父目录。我见过最典型的翻车是gaussdbLogPath写成了/var/log/gaussdb/（末尾多一个斜杠），安装工具解析出空目录名，直接报路径非法。

3.2 gs_preinstall 与 gs_install：两条命令分别在做什么

gs_preinstall是准备工序，它替你做四件事：创建 omm 用户和 dbgrp 用户组、创建安装目录并改属主、配置 ssh 互信、检查系统参数。所以它是用 root 跑的：

# 权限先放开，避免解压出来的文件 omm 读不到 chmod 755 -R /opt/software/openGauss cd /opt/software/openGauss/script # 交互模式，会提示输入 omm 用户密码 ./gs_preinstall -U omm -G dbgrp -X /opt/software/openGauss/cluster_config.xml

命令里的-U是数据库安装用户，固定用 omm 最省事；-G是用户组；-X指向刚才那份 xml。执行过程中会提示给 omm 设置密码，这个密码后面第一次登录数据库还要用，复杂度要求是至少 8 位，且包含大写字母、小写字母、数字、特殊字符中的至少三类，别用纯数字或者纯字母，会直接被拒。

如果想让脚本无人值守跑完，可以加--non-interactive，再配合-p传密码，但实验环境里我一般不用，交互模式每一步的输出更容易看清哪一步出了问题。preinstall 跑完，屏幕上会出现Preinstallation succeeded之类的字样，这时候去ls -l /opt/gaussdb看目录属主是不是 omm，是就说明这一步真的成了。

真正的安装用 omm 用户跑：

# 切到安装用户，注意是 su - 不是 su，要带上环境变量 su - omm cd /opt/software/openGauss/script gs_install -X /opt/software/openGauss/cluster_config.xml \ --gsinit-parameter="--encoding=UTF8" \ --dn-guc="max_connections=200" \ --dn-guc="password_encryption_type=1"

这行的参数值得单独说清楚：

• --gsinit-parameter="--encoding=UTF8"：初始化数据库时用 UTF8 编码。这一条别省，实验里要建中文姓名的学生表、教师表，编码不对，插进去就是问号，后面所有查询结果都是乱的。
• --dn-guc="max_connections=200"：数据库节点的最大连接数，实验环境 200 足够，多开几个 gsql 窗口加一个 JDBC 程序也不会顶掉。
• --dn-guc="password_encryption_type=1"：密码加密方式，改成 1 是为了兼容一些老版本 JDBC 驱动的认证方式。如果你只用 gsql 连，不写也行；要跑实验九的 JDBC 连接，加上更稳。

安装过程会打印进度，最后提示集群安装成功。如果中途失败，先别急着删库重装，去$GAUSSLOG下面找gs_install的日志，路径一般是/var/log/gaussdb/omm/om/gs_install-*.log，日志最后二十行基本就能定位原因。

3.3 omm 用户与 gsql：连上 26000 端口的默认 postgres

安装完成后，oom 用户的家目录下会多出一份.bashrc，里面写好了GAUSSHOME、LD_LIBRARY_PATH、PATH。这些变量不生效，gsql就会提示找不到命令：

# 保持 omm 身份，加载环境变量 source ~/.bashrc # 确认三个关键变量都在 echo $GAUSSHOME echo $LD_LIBRARY_PATH echo $PATH | grep -o "$GAUSSHOME/bin" # 查看集群状态，Normal 才算健康 gs_om -t status --detail

gs_om -t status是最常用的健康检查命令，输出里会列出每个实例的数据目录、端口和状态。状态不是Normal的，先gs_om -t start拉起来，起不来再看日志。

然后连默认库：

# -d 指定数据库，-p 指定端口，-r 让提示符更友好 gsql -d postgres -p 26000 -r

第一次连接会要求你改密码，因为初始化时设的是临时密码，不改不让进：

-- 把旧密码替换成你自己的新密码，注意两个密码都要满足复杂度 ALTER ROLE omm IDENTIFIED BY 'NewPass@2024' REPLACE 'OldPass@2023';

进去之后先认几个元命令，实验一的报告内容基本都靠它们出截图：

-- 列出所有数据库 \l -- 切换数据库 \c db_school -- 列出当前库的所有表 \dt -- 看某张表的完整定义，包括索引和约束 \d+ students -- 看表空间 \db -- 看用户和角色 \du -- 退出 \q

到这里数据库就算装完了。端口是 26000，默认库是 postgres，管理员用户是 omm，这三个信息在后续所有实验里都会反复用到。

4. 建库建表配参数：把实验二到实验六的前置条件一次搭好

装完只是有了一个空库，接下来要按实验报告的路径建用户、表空间、数据库、模式、表和索引。顺序错了就得返工，所以这一章按真实执行顺序写。

4.1 用户、表空间、数据库、模式：创建顺序不能乱

依赖关系是这样的：数据库要挂在某个表空间上，表空间要由某个用户拥有，所以先建用户，再建表空间，再建库。很多人一上来就CREATE DATABASE，跑完才发现默认落在系统表空间里，后面想挪还得重建。

-- 1. 建实验用普通用户，密码同样要满足复杂度 CREATE USER u_exp WITH PASSWORD 'Exp@2024db'; -- 2. 建表空间，relative location 是相对于数据目录的路径 CREATE TABLESPACE tpcds_local RELATIVE LOCATION 'tablespace/tablespace_1'; -- 3. 建库并指定表空间和属主 CREATE DATABASE db_school WITH TABLESPACE = tpcds_local OWNER = u_exp; -- 4. 改名，把演示用的库名改成实验要求的名字 ALTER DATABASE db_sc RENAME TO db_school;

RELATIVE LOCATION这个写法是 openGauss 的特点，路径相对于实例的数据目录，不是绝对路径。它有两个隐含要求：目标目录必须是空目录或者不存在，且属主是 omm。如果目录里已经有文件，会直接报directory is not empty。我一般先手工建好空目录再建表空间：

# 在 omm 用户下执行，路径要和 SQL 里的相对路径对上 mkdir -p $PGDATA/tablespace/tablespace_1

建完库切过去，再建模式。实验报告里对 schema 有专门的辨析，概念上的 schema 是一组 DDL 语句集，物理上的 schema 是库里的命名空间，实际建出来的是后者：

-- 切到新库 \c db_school -- 建一个实验用的模式 CREATE SCHEMA book_eg; -- 验证：应该能在列表里看到 book_eg \dn

\dn列出的就是当前库下所有模式。之后建表时如果不加模式前缀，表默认落在public下；想归到book_eg里，要么写全名book_eg.teachers，要么SET search_path TO book_eg一把切过去。

4.2 表、索引、视图与完整性约束：外键顺序和 \d+ 自检

建表最容易出错的地方不是语法，是顺序。Departments表有一个外键指向Teachers(Tno)，Students又指向Departments(Dno)，所以必须先建教师表，再建院系表，最后建学生表。

-- 教师表：主键 + 非空 + 性别检查约束 CREATE TABLE Teachers( Tno CHAR(20) PRIMARY KEY, Tname CHAR(20) NOT NULL, Sex CHAR(20) CHECK(Sex='男' OR Sex='女'), Birthday DATE, Title CHAR(20), Dno CHAR(20) ); -- 院系表：外键引用教师表，必须在教师表之后建 CREATE TABLE Departments( Dno CHAR(20) PRIMARY KEY, Dname CHAR(20), Dheadno CHAR(20), FOREIGN KEY (Dheadno) REFERENCES Teachers(Tno) );

列级约束和表级约束的区别在这里体现得很清楚：Sex的CHECK写在列定义后面，是列级约束；FOREIGN KEY单独一行写，是表级约束。规则很简单，只要约束涉及多个列，就必须写成表级。

建完一张就自检一张，别等全建完才发现错：

-- 看表的完整定义：字段、类型、约束、索引、所属表空间 \d+ teachers -- 只看结构，输出更简洁 \d teachers

\d+的输出里会明确列出Primary Key、Check constraints、Foreign-key constraints，逐条对一遍，比事后查错省时间。所有表建完，用\dt看总数，用\di看索引，主键会自动带一个索引，这一点实验报告里也要求说明。

创建索引的语法没什么花头，关键是选对列：

-- 学生表的院系编号经常出现在连接条件里，给它建索引 CREATE INDEX student_dept ON Students(Dno); -- 验证索引是否建上 \di

索引不是越多越好。这张学生表如果只有几十行数据，建了索引查询也不会变快，反而插入变慢。实验里要的是「会用」和「能解释为什么」，理由写「减少连接查询时的全表扫描」就够了。

视图这块，实验四的要求是用视图做数据抽象：

-- 只暴露学生姓名、专业和院系名，隐藏学号和出生日期 CREATE VIEW v_student_info AS SELECT s.Sname, s.Speciality, d.Dname FROM Students s JOIN Departments d ON s.Dno = d.Dno; -- 查视图和查表一样 SELECT * FROM v_student_info;

4.3 备份恢复与 JDBC：两处最容易被漏掉的配置

实验八的备份恢复、实验九的 JDBC 连接，是整份报告里最容易卡住的两个，因为它们的失败往往不在 SQL 层，而在文件路径和网络配置上。

备份用gs_dump，导出的是纯文本 SQL：

# 在 omm 用户下执行，先建好备份目录 mkdir -p /home/omm/backup # -f 输出文件，-p 端口，最后一个参数是数据库名 gs_dump -U u_exp -W 'Exp@2024db' -f /home/omm/backup/db_school.sql -p 26000 db_school

恢复用gs_restore或者直接gsql -f：

# 恢复到已有的库里 gsql -d db_school_new -p 26000 -f /home/omm/backup/db_school.sql # 或者用 gs_restore 走自定义格式包 gs_restore -d db_school_new -p 26000 /home/omm/backup/db_school.dmp

JDBC 连接需要两处改动，缺一不可。第一处是监听地址，让数据库接受非本机连接：

# 在 omm 用户下找到数据目录 gsql -d postgres -p 26000 -c "SHOW data_directory;" # 编辑 postgresql.conf，把监听地址放开 vim $PGDATA/postgresql.conf # 找到 listen_addresses，改成： # listen_addresses = '*'

第二处是客户端认证，在pg_hba.conf末尾加一行，允许实验网段用密码登录：

vim $PGDATA/pg_hba.conf # 追加一行，网段换成你虚机所在网段 # host all all 192.168.56.0/24 sha256

改完必须重启集群，配置才生效：

gs_om -t restart

Java 侧的连接代码大致是下面这样，重点是驱动类名和 URL 前缀，openGauss 用的是jdbc:opengauss://，不是jdbc:postgresql://：

// 加载 openGauss 驱动，jar 包要放在 classpath 里 Class.forName("org.opengauss.Driver"); // sslmode=disable 用于实验环境的无证书连接 String url = "jdbc:opengauss://192.168.56.10:26000/db_school?sslmode=disable"; Connection conn = DriverManager.getConnection(url, "u_exp", "Exp@2024db"); // 简单查询验证链路 Statement st = conn.createStatement(); ResultSet rs = st.executeQuery("SELECT count(*) FROM Students"); while (rs.next()) { System.out.println(rs.getInt(1)); }

sslmode=disable这个参数不加，很多情况下会报 SSL 握手失败，因为服务端没配证书而客户端默认要求加密。

5. 避坑与排查：五个把我卡到凌晨的场景

下面这五条都是实际装的时候撞出来的，按「现象是什么、为什么会这样、怎么解」记。

第一条：gsql连本机也报 connection refused。

现象是gs_om -t status显示 Normal，但gsql -d postgres -p 26000提示连接被拒。原因通常是集群只是「已安装」，进程没真正起来，或者端口被别的服务占着。先gs_om -t start再试，还不行就看端口占用ss -lntp | grep 26000，以及$GAUSSLOG/pg_log下最新的日志，里面会写清楚是监听失败还是启动参数不对。

第二条：gs_preinstall卡在 ssh 互信，报 trust relationship failed。

现象是脚本跑到配置互信那一步停住，反复重试后失败退出。原因基本是hostname和/etc/hosts对不上，或者 omm 用户的家目录权限被别人动过。解法是先ping node1和ssh node1手工验证，确认能通；再把/home/omm权限改回700，属主 omm，然后重跑 preinstall。重跑之前记得把上一次残留的~/.ssh清掉。

第三条：建表空间报 directory is not empty。

现象是CREATE TABLESPACE ... RELATIVE LOCATION提示目录非空。原因是那个相对路径下已经有文件，可能是上一次实验留下的，也可能是你手工mkdir之后往里放了东西。解法是清空目录再建，或者换一个新的子目录名。注意别直接用rm -rf删数据目录，先ls看清楚。

第四条：远程 JDBC 连接报 no pg_hba.conf entry。

现象是本地 gsql 一切正常，Java 程序连过来报认证条目缺失。原因是pg_hba.conf里只有本地 socket 的规则，没有 host 规则。改pg_hba.conf加一条host all all 网段 sha256，再gs_om -t restart。改完用gsql -h 192.168.56.10 -p 26000 -d postgres先验证远程能连，再跑 Java。

第五条：中文数据插进去变成问号。

现象是建表时字段类型没问题，插入「张三」查出来是乱码。原因是数据库初始化时没有指定 UTF8 编码，或者客户端client_encoding跟服务端不一致。前者只能重装解决，所以第 3 章那条--encoding=UTF8千万别省；后者在 gsql 里执行SET client_encoding TO 'UTF8';就能当场验证。

6. 装完怎么验证：从 gs_om 到 JDBC 跑通一条完整链路

装完不等于装好，我现在每次装完都强制走一遍下面这条链路，全程不超过五分钟，但能挡掉九成的隐患。

第一步看集群状态，这是所有检查的起点：

su - omm source ~/.bashrc gs_om -t status --detail

输出里每个实例的状态必须是Normal，端口必须是 26000。状态不对的，后面的步骤全都不用做了，直接去$GAUSSLOG翻日志。

第二步验证本地连接和对象可见性，一条命令串起来：

gsql -d db_school -p 26000 -r -c "\dt" -c "\di" -c "\dn"

三个元命令分别对应表、索引、模式。表清单跟你建的对得上，索引里能看到主键自动生成的索引和手工建的那一个，模式列表里有book_eg，说明实验二到实验四的东西都在。

第三步验证远程连接和权限，用主机 IP 而不是 localhost：

gsql -h 192.168.56.10 -p 26000 -d db_school -U u_exp -W 'Exp@2024db' -c "SELECT count(*) FROM Students;"

这一步能过，说明listen_addresses和pg_hba.conf两处配置都对了。过不了就回到第 5 章第四条。

第四步验证备份恢复，这是最容易被跳过、又最能暴露路径问题的一步：

gs_dump -U u_exp -W 'Exp@2024db' -f /home/omm/backup/check.sql -p 26000 db_school ls -lh /home/omm/backup/check.sql head -20 /home/omm/backup/check.sql

导出的文件应该有实际内容，head能看到CREATE TABLE语句。如果文件是 0 字节或者只有几行注释，多半是权限问题或者库名写错了。

最后一步是 JDBC，跑一个只有 main 方法的小程序，打印一行查询结果就行。表里数据不多的时候，我习惯用SELECT count(*)加上一条SELECT Sname FROM Students LIMIT 3，既能验证连接，又能顺带确认中文没有乱码。

这套检查我第一次写的时候嫌麻烦，觉得装都装好了还查什么。后来有一次交实验报告前夜发现备份文件是空的，从头查到凌晨三点才定位到是gs_dump的-p参数写成了本机另一个实例的端口。从那以后我每次装完环境，不管多晚，gs_om -t status、\dt、gs_dump这三步都强制走一遍，确认过了再去写报告里的实验内容。希望这套流程能帮你少走一遍我走过的夜路。

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