资讯详情

openGauss数据库原理实验全流程:从gsql连接到JDBC联调

📅 2026/11/4 12:44:27 | 华诺云谱 👁 阅读
openGauss数据库原理实验全流程:从gsql连接到JDBC联调
简介zzu《数据库系统原理实验》报告书面向计算机科学与技术、软件工程专业学生围绕openGauss数据库环境完整记录了从认识DBMS、创建数据库、表和索引到交互式SQL语句、创建视图、完整性控制、安全性控制、事务与并发控制、数据库备份与恢复以及使用JDBC连接数据库共九个实验的实践过程。每个实验均给出实验目的、内容、类型与学时分配并附有操作截图、实验过程中遇到的问题、更正方式及结果分析可供课程实验对照、课后复盘与实验报告撰写参考。压缩包内共1个docx文件约3.23MB按前言与实验一至实验九顺序编排目录层次清晰便于按实验模块快速检索。已有1527人学习适合正在修读数据库实验课、需要参照范例完成openGauss实操与报告整理的学生使用。1. 带新人做数据库实验真正卡人的不是 SQL带 A 同学做数据库课程实验那阵最难的不是让他写出多表连接而是 openGauss 装完之后gsql死活连不上折腾两天才发现是没切到omm用户、环境变量全在别人家。这份《数据库系统原理实验》报告书把九次实验串成了一条完整链路认识 DBMS、建库建表建索引、交互式 SQL、视图、完整性控制、安全性控制、事务与并发、备份与恢复、JDBC 连接数据库。它面向计算机类与软件工程专业的数据库原理实验课以 openGauss 为承载平台从装库、连接一路走到写 Java 代码读写表。适合三类人赶实验报告的学生、想补数据库动手能力的转岗开发者、需要一套能跑通的教学案例的授课者。下面按“能照着复现”的顺序拆。2. 环境与连接三种装法怎么选gsql 进去先看哪几眼装 openGauss 这件事选错安装方式会直接把后面八个实验的时间全赔进去。报告书里列了三种云主机上装、虚拟机一键安装、先装 openEuler 再手动装 openGauss。这三种不是平级选项它们的差别在“你能看见多少系统内部”而不只是快慢。2.1 三种安装路径的取舍与实验环境的最低要求一键安装包的逻辑是把安装脚本、依赖、初始化全打包跑完就有库。好处是半小时内能进gsql坏处是路径、端口、数据目录全由脚本决定一旦起不来日志散落在好几个位置新手根本不知道从哪看。手动装在 openEuler 上则相反你得自己建omm用户、自己指定安装目录和数据目录常见做法是软件装/opt/software/openGauss数据目录用-D参数指到独立磁盘分区慢但每一步都可控。我一般建议第一次做实验用一键安装把流程跑通交报告前再手动装一遍因为实验一的教学目标写得很清楚——“了解 DBMS 的工作原理和系统架构”一键装完你连数据文件放哪都不知道这个目标就是空的。装之前的系统准备有几条是硬性的漏一条就装不上检查项要求不满足的后果内存建议 8G 以上最小不低于 4G初始化阶段被 OOM 杀掉日志里只有一行 killed磁盘数据目录单独分区预留 20G 以上建完表空间就写满后续实验全部失败主机名全小写、不含下划线和特殊字符安装脚本校验直接退出防火墙与安全模块实验环境内关闭本机连得上远端 26000 端口不通字符集与时区UTF8、与系统一致中文姓名写入乱码CHECK约束判断异常用户专用安装用户报告里是omm不用 root 跑库权限混乱后续gs_dump备份失败这张表里的“主机名不能带下划线”是最容易被忽略的一条很多人装到一半报错回头改主机名结果 PostgreSQL 系的初始化已经写了一半只能删目录重来。2.2 gsql 连接与元命令\l、\dt、\d各自回答什么问题装完之后第一件事不是建库是确认服务在跑。所有操作都必须在omm用户下执行因为环境变量GAUSSHOME、LD_LIBRARY_PATH是写在它的.bashrc里的# 切换到数据库安装用户注意是 su - 不是 su要重新加载环境变量 su - omm # 查看数据库服务状态--detail 会列出主备节点和端口 gs_om -t status --detail # 启动服务停止是 gs_om -t stop gs_om -t start # 连接默认数据库 postgres26000 是主节点端口-r 让实际执行的语句回显出来 gsql -d postgres -p 26000 -r这里几个参数值得说一下。su - omm中间的横杠不能省省了就是“以 omm 身份但保留原用户环境”gsql会提示找不到命令。-d postgres指定连哪个库postgres是安装完默认生成的库可以直接在里面建新库。-p 26000是端口装的时候改过就要跟着改端口写错的表现是“连接被拒绝”而不是“密码错误”这两个报错要分得清。-r是回显实验报告要求截图和语句对应开着它截图会更清楚。进去之后元命令是效率的关键。报告书里列了一串我按“回答什么问题”重新归类元命令回答的问题等价系统表查询\l这台实例上有哪些数据库select datname from pg_database;\c dbname切换到某个库无\c - username换个用户身份重连无\dt当前库里有哪些表select * from pg_tables;\d tablename这张表有哪些列、约束、索引、存储参数\d的加强版\dn有哪些模式schema查pg_namespace\di有哪些索引查pg_indexes\db有哪些表空间select spcname from pg_tablespace;\du有哪些用户和角色select * from pg_roles;\h某条 SQL 的语法帮助无\q退出无\d和\d的差别要记住\d tablename看表结构够用\d会多出存储方式、压缩、分布列这类信息openGauss 是分布式的建表时如果不指定分布列默认按第一个满足条件的列散列\d能看出它选了谁。这个细节在后面做事务和并发实验时会变成坑——不同会话可能落在不同节点上。系统表查询也建议练一遍因为元命令本质就是包装过的查询理解系统表才能排查权限问题-- 当前实例的全部数据库 select datname from pg_database; -- 全部表空间系统和用户定义的都在里面 select spcname from pg_tablespace; -- 用户与角色的关系rolcanlogin 为真才是可登录用户 select rolname, rolsuper, rolcanlogin from pg_roles;pg_roles里的rolcanlogin是个很实用的字段create role建出来的默认不能登录create user建出来的可以很多“建了账号却登不上”的问题根子就在这。2.3 用户与模式为什么建完用户还要单独授权实验一要求“创建数据库用户和数据库”。默认只有安装时创建的管理员能访问初始库所以要另建账号。这里有两个概念必须分清报告书里那段辨析写得不错但偏教科书我换个说法用户是能登录的账户角色是权限的集合。给某个人一堆权限不是一条条grant给他而是建一个角色、把权限给角色、再把角色给这个人。公司新来一个库管员直接赋予库管角色他就有了整套权限他调去销售部门换个角色就完了。这个模型在建库初期看不出好处等到实验六做安全性控制要给五六个人配不同权限时差距就出来了。模式则是库内部的命名空间。一个库可以有多个 schemabook_eg.Teachers和public.Teachers是两张不同的表互不冲突。物理 schema 就是“一组表、视图、存储过程的名字空间”可以create、alter、drop。-- 建一个实验用的普通用户密码需要满足复杂度长度 8 位以上 -- 且包含大写字母、小写字母、数字、特殊字符中的至少三类 create user u_exp identified by Exp2024db; -- 建一个角色把一组权限挂上去 create role r_readonly; -- 允许该用户连接 db_school 库库还没建的话先跳过建完再执行 grant connect on database db_school to u_exp; -- 授予模式的使用权没有这一步用户看得到库但看不到里面的表 grant usage on schema book_eg to r_readonly; -- 授予具体表的查询权 grant select on all tables in schema book_eg to r_readonly; -- 角色分配给用户 grant r_readonly to u_exp;这段的关键在第三、四行。connect只解决“能不能进这个库”usage on schema解决“能不能看见这个模式里的对象”表级select解决“能不能读数据”。三样缺一样用户登录后都会得到“表不存在”或“权限不足”而这两种报错长得完全不一样是后面排查章节的重点。3. 从表空间到索引db_school这套库表怎么一次建对实验二要建的东西层次很多表空间、数据库、模式、六张表、若干索引。它们的创建顺序不是随便排的顺序错了会得到一堆does not exist。3.1 表空间、数据库、模式三层的创建顺序与相对路径先把三者的关系摆清楚不然建的时候会一直混对象是什么归属关系能否跨库表空间数据文件存放的物理位置实例级一个表空间可被多个库共用是数据库一套独立的数据集合实例级库之间默认不互通—模式库内部的命名空间库级一个库可有多个模式否报告书里用“文件夹”打比方表空间像专门放某类资料的文件夹数据库是划分出来的一块存储空间。这个比方不算精确但够用真正要记住的是表空间是物理层模式是逻辑层两者不在一个维度上别把它们当成同一层的东西来理解。建表空间用的是相对路径这个相对是相对于数据目录而且目录必须事先存在、必须为空、必须归omm所有# 在数据目录下建空目录路径以实际安装时的 -D 参数为准 mkdir -p /var/lib/opengauss/data/tablespace/tablespace_1 chown -R omm:omm /var/lib/opengauss/data/tablespace chmod 700 /var/lib/opengauss/data/tablespace/tablespace_1-- 相对路径相对于数据目录所以只写 tablespace/tablespace_1 create tablespace tpcds_local relative location tablespace/tablespace_1; -- 建库时指定默认表空间 create database db_sc with tablespace tpcds_local; -- 改名 alter database db_sc rename to db_school; -- 切库元命令在 gsql 里执行 \c db_school -- 在库里建模式 create schema book_eg;create tablespace那行有三个失败点目录不存在、目录非空、目录属主不是omm。三种情况的报错措辞不一样但都指向同一件事——数据库进程没权限往那个目录写。实验环境里最省事的做法就是先chown omm:omm再chmod 700别用 777openGauss 会拒绝权限过宽的目录。create database后面跟with tablespace 等号两边可以有空格也可以没有但库名不能和已有库重名。改名用alter database ... rename to ...注意不能在当前连接的库上给自己改名得先\c postgres切走。3.2 六张表的建表顺序与外键依赖实验二的表是经典的教务模型Teachers、Departments、Students、Courses、SC选课、Teaches授课。外键把它们连成一张有向图建表顺序必须按依赖从上游到下游Teachers ── Departments ── Students Courses ── SC ── Students Teachers ── Teaches ── Courses但报告书里埋了一个真实的设计问题Teachers表里有Dno字段指向院系Departments表里有Dheadno字段指向教师——这是循环引用。循环引用没法用一条create table解决必须先把两张表建出来再用alter table补其中一个外键。原文那句“由于关系中存在相互参照需要通过修改表添加表级约束”说的就是这件事。-- 第一张教师表先不建 Dno 的外键因为院系表还没建 create table Teachers( Tno CHAR(20) primary key, Tname CHAR(20) not null, Sex CHAR(20) check(Sex in (男,女)), Birthday DATE, Title CHAR(20), Dno CHAR(20) ); -- 第二张院系表负责人外键指向教师表此时教师表已存在 create table Departments( Dno CHAR(20) primary key, Dname CHAR(20), Dheadno CHAR(20), constraint fk_dept_head foreign key (Dheadno) references Teachers(Tno) ); -- 回补教师表到院系表的外键解决循环引用 alter table Teachers add constraint fk_teacher_dept foreign key (Dno) references Departments(Dno); -- 学生表依赖院系表 create table Students( Sno CHAR(20) primary key, Sname CHAR(20) not null, Sex CHAR(20) check(Sex in (男,女)), Birthday DATE, Enrollyear CHAR(20), Speciality CHAR(20), Dno CHAR(20), constraint fk_stu_dept foreign key (Dno) references Departments(Dno) ); -- 课程表无外部依赖 create table Courses( Cno CHAR(20) primary key, Cname CHAR(20) not null, Period SMALLINT, Credit SMALLINT ); -- 选课表同时依赖学生和课程 create table SC( Sno CHAR(20), Cno CHAR(20), Grade SMALLINT, constraint pk_sc primary key (Sno, Cno), constraint fk_sc_stu foreign key (Sno) references Students(Sno), constraint fk_sc_course foreign key (Cno) references Courses(Cno) ); -- 授课表依赖教师和课程 create table Teaches( Tno CHAR(20), Cno CHAR(20), constraint pk_teaches primary key (Tno, Cno), constraint fk_tch_teacher foreign key (Tno) references Teachers(Tno), constraint fk_tch_course foreign key (Cno) references Courses(Cno) );逐段说逻辑。Teachers的Dno故意不加外键原因就是循环依赖。Departments建的时候教师表已经在所以它的外键可以直接写在建表语句里。建完Departments立刻回头alter table Teachers补外键顺序不能颠倒。SC和Teaches用的是复合主键因为一个学生可以选多门课、一个老师可以教多门课单列做主键会冲突。复合主键的写法是把两列写在同一个primary key (Sno, Cno)里不能分别写primary key那样会报“多重主键”。SMALLINT用在Period和Credit上是有讲究的。无符号SMALLINT的范围是 0 到 65535INT是 4 字节、范围到 21 亿学分和学时根本用不到那么宽。选窄类型不只是省空间还能让非法值比如负数学分在类型层面就被挡住一部分虽然严格来说还要靠CHECK约束。建完用\dt确认六张表都在用\d Teachers确认外键真的加上了。\d的输出里有Foreign-key constraints一节如果fk_teacher_dept没出现说明那句alter没执行成功。有人会问能不能不管顺序全部建完再统一加外键可以把所有外键都写成alter table ... add constraint ...顺序就自由了。代价是建表语句里看不出关系报告里不好讲解所以实验场景我还是建议按依赖顺序建、只给循环引用的那一处留alter。3.3 索引\di能看到什么什么样的列值得建实验二最后一步是建索引报告里给的例子是在Students.Dno上建Student_Dept-- 在学生表的院系编号列上建普通索引 create index student_dept on Students(Dno); -- 查看当前库的所有索引 \di -- 更细的方式直接查系统表能看到索引对应的表 select indexname, tablename, indexdef from pg_indexes where schemaname book_eg; -- 看某条查询走不走索引重点看 Seq Scan 还是 Index Scan explain select * from Students where Dno D01;参数和逻辑create index后面跟索引名on后面跟表名和列名。索引名在全库范围内要唯一跟表名重名会报错。建索引只对“按这列过滤或连接”的查询有用对select *全表扫描没用。主键会自动建索引这是报告里明确提到的一点。所以Teachers.Tno、Students.Sno、Courses.Cno都已经有索引了不需要重复建重复建只是浪费空间和写入时间。什么列值得建我给个实操判断外键列优先建。Students.Dno、SC.Sno、SC.Cno这类列会被大量用于连接和级联检查没索引时连接会走嵌套循环数据一多就慢得离谱。注意 openGauss 不会自动给外键建索引这点和主键不同要手动加。高频出现在where等值条件里的列建。区分度低的列比如Sex只有两个值不建优化器大概率不用它白占空间。更新极其频繁的列慎建每次update都要维护索引。小表不建几十行的表全表扫描比走索引还快。explain是验证索引有没有生效的唯一可靠手段。实验报告里如果只贴了create index的成功提示没有贴执行计划那这份报告的说服力是不够的——索引建了不等于用了。4. 完整性、安全性与并发约束、授权、事务三个实验的落地写法从实验五到实验七主题从“建东西”转向“管东西”这三块最容易写成流水账因为语法都短几行就完了看不出所以然。真正值得写进报告的是“为什么这样约束”和“违反时数据库怎么反应”。4.1 列级约束与表级约束落点不同能力也不同报告书里对列级约束和表级约束的辨析写得很细核心就三句话列级约束写在列定义后面表级约束写在所有列之后列级支持not null和default表级不支持表级可以起约束名列级主键除外不行。为什么表级约束不能写not null因为not null描述的是“这一列的值不能为空”它天然只属于单列没有“多列联合非空”这种语义。而check可以跨列比如“结束日期必须晚于开始日期”这种就必须写表级。-- 列级 check只作用于 Sex 这一列 create table Demo_A( id CHAR(10) primary key, sex CHAR(2) check (sex in (男,女)) ); -- 表级 check可以引用多列且能命名方便后续按名字删除 create table Demo_B( id CHAR(10) primary key, begin_d DATE, end_d DATE, constraint ck_date_order check (end_d begin_d) ); -- 验证这条会失败报违反 ck_date_order insert into Demo_B values (1, 2024-09-01, 2024-08-01); -- 命名约束的好处出问题时能定位 alter table Demo_B drop constraint ck_date_order;第三段是重点。不加名字的约束数据库会自己生成一个Demo_B_check1之类的名字等你要删它或者看报错日志时只能靠猜。只要约束有可能被修改或删除就一定命名这是我踩过的坑。三类完整性在这里对应得很清楚实体完整性靠主键primary key非空且唯一参照完整性靠外键foreign key值必须来自被引用列或为null用户定义完整性靠check和not null。实验五的验证方法就是往表里插违反约束的数据看数据库是否拒绝然后把报错原文抄进报告——报错信息里带着约束名这也是命名约束的价值。外键还有两个常被忽略的选项on delete cascade和on update cascade。默认行为是no action即被引用行还有子行时拒绝删除父行。做级联删除的实验时如果没写cascade删父表数据会报“违反外键约束”这不是 bug是保护机制。实验报告里应该把两种行为都跑一遍对比结果。4.2 角色与权限最小授权集怎么配revoke什么时候生效实验六的安全性控制很多人做成“建个用户、给个all privileges、完事”。这样报告是能交但完全没体现出“控制”二字。最小授权的思路是只给完成工作必需的那部分多一条都不给。-- 场景只允许查询学生姓名和专业不允许看生日等敏感字段 -- 做法一列级授权 grant select (Sname, Speciality) on Students to u_exp; -- 做法二建只读角色统一管理 create role r_stu_reader; grant usage on schema book_eg to r_stu_reader; grant select on Students, Courses to r_stu_reader; grant r_stu_reader to u_exp; -- 回收权限注意回收角色和回收表权限是两回事 revoke select on Courses from r_stu_reader; -- 查看某用户最终拥有的权限 \du u_exp select * from information_schema.table_privileges where grantee u_exp;列级授权是 openGauss 支持但很多人不知道的能力grant select (列名列表) on 表名这种写法可以直接把敏感列挡在外面。验证方式是用u_exp登录select * from Students会失败select Sname from Students会成功——这个对比放进报告比贴十行grant all有说服力。revoke的生效时机要注意它只影响后续的权限检查已经建立的会话如果缓存了权限可能要重连才看得到变化。实验时如果revoke完发现还能查先\c - u_exp重连一次再判断。还有一个高频问题给用户授了表权限他登录却说“表不存在”。这不是权限不足是缺usage on schema——没有模式的可见性里面的对象对他等于不存在。这两个报错必须分清楚排查章节还会再提。4.3 事务与并发用两个会话把现象复现出来实验七的事务与并发控制是整套实验里最容易糊弄过去的一节因为单会话下事务看起来只是“多打两个关键字”。真正的理解要靠两个gsql窗口对着跑。-- 会话 A begin; update SC set Grade 90 where Sno S01 and Cno C01; -- 此处不提交保持事务打开 -- 会话 B另开一个 gsql 窗口同一个用户 update SC set Grade 95 where Sno S01 and Cno C01; -- 这条会阻塞直到 A 提交或回滚A 不提交时B 的update会一直等这是行锁在起作用。A 一旦commitB 立刻继续A 如果rollbackB 拿到的还是旧值。用select * from pg_locks能看到等待中的锁这是证明“锁真的存在”的硬证据比文字描述强。隔离级别方面openGauss 默认是读已提交read committed能防脏读防不住不可重复读和幻读。复现不可重复读的做法-- 会话 A begin; select Grade from SC where Sno S01 and Cno C01; -- 第一次读到 90 -- 会话 B update SC set Grade 95 where Sno S01 and Cno C01; commit; -- 会话 A 再读一次同一事务内前后不一致这就是不可重复读 select Grade from SC where Sno S01 and Cno C01; -- 读到 95 commit;想避免就把隔离级别提到可重复读但代价是并发性能下降、可能出现序列化失败需要重试。实验报告里把这个权衡写出来比背定义有价值得多。死锁也值得跑一遍A 先更新第一行再更新第二行B 反着来两边互相等。数据库检测到后会主动回滚其中一个事务报错信息里明确写着检测到死锁。这个报错是正常现象不是环境坏了报告里应该把它作为“死锁被自动处理”的证据贴出来。5. 避坑与排查openGauss 实验里最容易翻车的五处这五条是这类实验里出现频率最高的每条都按“现象→原因→解决”写遇到时按顺序对号入座就行。第一条gsql报“命令未找到”或“连接被拒绝”。现象是执行gsql -d postgres -p 26000 -r直接提示找不到命令或者提示could not connect to server。命令找不到的原因是没切对用户gsql的可执行路径在omm的环境变量里普通用户执行当然没有连接被拒的原因是服务没起或者端口不对。解决办法是先su - omm带横杠再gs_om -t status --detail看服务状态Port那一行才是真实端口。如果状态是Down执行gs_om -t start起来之后再连。起不来的话去看数据目录下的pg_log里面有一次启动失败的完整原因从最后一行往前读。第二条建表空间报“目录不存在”或“权限不足”。现象是create tablespace ... relative location tablespace/tablespace_1失败。原因是相对路径的基准是数据目录不是你当前所在的目录而且这个目录必须事先存在、必须为空、属主必须是omm。解决方法是先cd到数据目录确认路径手工mkdir、chown omm:omm、chmod 700再执行建表空间语句。目录非空也会失败哪怕里面只有一个隐藏文件。第三条建表报“relation does not exist”卡在循环引用上。现象是建Departments时引用Teachers或者建Teachers时引用Departments总有一边报被引用的表不存在。原因是两张表互相引用不可能同时建出来。解决办法是挑一张先建、暂时不写外键建完第二张再用alter table 第一张 add constraint ... foreign key ...回补。这也是报告里那句“通过修改表添加表级约束”的由来。第四条新用户登录后查表报“表不存在”或“权限不足”。现象是用户明明被grant过登录后select还是失败。原因分两种报“表不存在”是缺usage on schema对象对他不可见报“权限不足”是缺表级select。解决办法是分别补grant usage on schema 模式名 to 用户和grant select on 表名 to 用户补完让用户重连一次。另外还要确认该用户有库级的connect权限三样缺一不可。第五条删库或删模式时报“有其他对象依赖”。现象是drop database db_school或drop schema book_eg失败。原因是有表、视图、索引还挂在这个对象上。解决办法是删模式用drop schema book_eg cascade连带删除内部对象删库不能在当前连接的库上执行得先\c postgres切走再drop database。cascade会连带删掉所有依赖对象包括视图用之前确认没有还要保留的东西。6. 备份恢复与 JDBC 联调把实验八、九做成可复用脚本实验八和实验九放在最后是因为它们把前面所有东西收口备份验证了库结构完整JDBC 验证了库能被程序访问。这两件事都有个共同点——手工点一遍很容易写成能重复跑的脚本才有价值。6.1 用gs_dump做一次可回滚的备份验证逻辑备份用gs_dump导出的是 SQL 文本可以只导结构、只导数据、或者全导。验证备份是否可用的唯一方法是真恢复一次放在另一个库上做别动原库# 在 omm 用户下执行-F p 表示纯文本格式-f 指定输出文件 gs_dump -U omm -W YourPassword -p 26000 -F p -f /home/omm/db_school_bak.sql db_school # 只导结构不导数据做结构对比时有用 gs_dump -U omm -W YourPassword -p 26000 -s -f /home/omm/db_school_schema.sql db_school # 恢复到新库先建空库再灌入 gsql -d postgres -p 26000 -c create database db_school_restore; gsql -d db_school_restore -p 26000 -f /home/omm/db_school_bak.sql参数说明-F p是纯文本可读性好、便于改大库用-F c自定义格式压缩后更小但需要gs_restore来恢复。-W后面接密码会留在 shell 历史里实验环境无所谓正式环境应该用.pgpass或者交互输入。-s只导结构-a只导数据。恢复完一定要核对不能只看“没报错”核对项命令期望结果表数量\dt与原库一致六张表都在表结构\d Students列、约束、外键名一致数据行数select count(*) from SC;与原库相同索引\di索引名和列一致我见过只导不验的备份真出事时才发现导出的文件里少了外键——因为导出时用了-s加某些参数组合约束被跳过。备份的价值在恢复不在导出成功。6.2 JDBC 连接串与三个必须改的参数实验九用 JDBC 连库核心就三样驱动 jar、连接串、一句查询。驱动包常见做法是引opengauss-jdbc驱动类名是org.opengauss.Driver连接串格式jdbc:opengauss://主机:端口/库名。import java.sql.*; public class DbDemo { public static void main(String[] args) throws Exception { // 连接串主机、端口 26000、库名三处必须和实际环境一致 String url jdbc:opengauss://127.0.0.1:26000/db_school; // 第一个必改项ssl。服务端未配 SSL 时必须显式关掉否则握手超时 url ?sslfalse; // 第二个必改项连接超时单位秒避免网络不通时一直挂着 url loginTimeout5; // 第三个必改项应用名排查连接来源时能在服务端看到 url ApplicationNamedb_lab_demo; try (Connection conn DriverManager.getConnection(url, u_exp, Exp2024db); Statement st conn.createStatement(); ResultSet rs st.executeQuery( select Sno, Sname, Speciality from Students order by Sno)) { while (rs.next()) { System.out.println(rs.getString(1) \t rs.getString(2) \t rs.getString(3)); } } } }三处参数逐一说。sslfalse是最常见的翻车点服务端默认没开 SSL客户端驱动默认又尝试加密连接表现是连接卡住几秒然后抛异常报错里提到 SSL 握手。loginTimeout5把“网络不通”这种失败从无限等待变成 5 秒超时调试时省时间。ApplicationName在服务端pg_stat_activity里能看到多人同时连库时能分辨哪个连接是自己的。另外用try-with-resources包住Connection、Statement、ResultSet不是风格问题是必须的——不关连接实验跑几十次就会把连接数吃满后面再连报“too many clients”。这个坑我在学生机上见过不止一次。从那以后我每次做数据库实验都强制自己走一遍“装完先gs_om -t status --detail、建表先画依赖图、备份必恢复验证”这三步宁可多花二十分钟也不在最后交报告前返工。这份报告书的价值不在于它写得多全而在于它把九个实验按依赖顺序串成了一条能走通的路径照着走中间那些本可以避免的坑基本都能绕过去。希望帮到你。本文还有配套的精品资源点击获取
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。

↑