人大金仓KingbaseES实战指南：从Oracle兼容到数据库迁移部署

1. 为什么现在都在问“人大金仓”——先搞清楚这台数据库是干嘛的

最近在技术交流群里被问得最多的一个词，除了MySQL就是“人大金仓”。很多人第一次听到这个名字，第一反应是“这又是哪个国产数据库”。没错，它就是国产数据库里的一支老牌力量，全称叫人大金仓数据库，产品核心是KingbaseES。如果你正在做课程设计、公司信创项目选型，或者面试前临时补课，这篇就是给你准备的。

人大金仓这个产品，一句话概括就是：一套基于PostgreSQL内核、兼容Oracle语法特性、面向企业级应用的关系型数据库管理系统。翻译成人话就是——你以前写的Oracle SQL，改一改就能在它上面跑；你以前会的PostgreSQL运维手段，大部分也能直接复用。这对于那些被要求“去O”、又要保证业务不大改的团队来说，吸引力是真的大。

那它到底解决了什么问题？往大了说，它属于国产基础软件替代的一环，很多政务、金融、能源、电信的项目都明确要求数据库选型必须国产化。往小了说，如果你只是想完成一个数据库课程设计，或者想在简历里加一项“国产数据库使用经验”，人大金仓也是一个非常合适的学习对象——它能装Docker里，能跑在普通笔记本上，语法又跟Oracle和PostgreSQL都有血缘关系，学一遍相当于同时复习了两种主流数据库。

这篇文章我会从它是什么、底层设计怎么理解、怎么快速部署、日常开发怎么用、怎么迁移数据、面试怎么答这几个角度，把我实际使用过的经验和踩过的坑一次性讲透。不管你是零基础的学生，还是被项目逼着上手的开发，这篇文章应该都能让你少走不少弯路。

1.1 人大金仓的前世今生：从实验室到生产系统的关系型数据库

先花一分钟聊聊背景，方便你理解它的定位。人大金仓的“人大”两个字，不是随便挂的，它是中国人民大学在数据库方向上的科研成果转化。早期这个团队主要做的是分析型数据库，后来整合进了KingbaseES这条完整的企业级关系型数据库产品线。所以你在很多政企项目的标书里看到的“人大金仓”三个字，指的基本就是KingbaseES。

从技术路线上看，KingbaseES选择了PostgreSQL作为内核底座。这个选择当时看起来不起眼，但如今回头看非常关键。PostgreSQL本身就以功能全面、扩展性强著称，而且社区生态庞大，各种插件、工具链都很成熟。金仓在它上面做了一层很厚的“中国特色”改造，重点就是Oracle兼容能力、国产软硬件适配能力、以及安全合规能力。也就是说，它并不是简单换个皮，而是有大量自研的工作量在里面。

这也解释了为什么金仓的文档里你会看到很多熟悉的影子——比如sys_开头的系统视图，看起来像极了pg_开头的PostgreSQL系统视图；又比如它支持ROWNUM、SYSDATE、NVL这类Oracle函数。这种“底下是PG、上面兼容Oracle”的架构，让它在国产数据库里走出了差异化路线：既保留了开源社区的丰富生态，又能让存量Oracle业务平滑迁移。

1.2 金仓能干什么：典型应用场景与适合人群

金仓的定位是通用关系型数据库，所以理论上你能用MySQL做的场景，它基本都能做。但实际项目里，它出现得最多的地方，还是那几个典型领域：

一是政务和大型国企的信息系统。这类系统的特点是，业务稳定、SQL语法老旧、大量使用存储过程和复杂视图，而且对数据安全要求极高。金仓的Oracle兼容能力在这里就派上了大用场，很多原本跑在Oracle上的报表系统、审批系统，迁移到金仓后甚至不用改SQL。

二是教育科研场景。很多高校的数据库原理课程、课程设计、毕业设计都在用金仓，一方面是因为学校有正版授权，另一方面是因为金仓的体系完整，从单机版到集群版都有，适合做各种实验。如果你在准备数据库课程设计，用金仓做一个带增删改查、事务处理、权限管理的小系统，完成度会显得很高。

三是有国产化替代需求的中小型企业。这类企业可能预算有限，但又必须响应国产化要求。金仓的社区版、开发版降低了试用门槛，团队只要懂PostgreSQL就能很快上手。

至于适合谁来学，我觉得范围其实很宽：还在读书的学生、做Java后端开发的程序员、负责数据库运维的DBA、甚至做数据迁移项目的项目经理，都有必要了解一下金仓。学生可以拿它刷课程设计和面试经验，开发可以拿它应对国产化改造项目，DBA可以学它的备份恢复、性能调优、高可用架构。多掌握一套数据库，在职场上的选择面就会宽很多。

1.3 人大金仓、达梦、OceanBase……国产数据库到底怎么选

既然说到了解金仓，就绕不开“国产数据库选哪个”这个经典问题。市面上你现在听到最多的几个名字，除了人大金仓，还有达梦、OceanBase、openGauss、GaussDB、PolarDB等。它们各有各的侧重点，简单做个对照。

如果只是做技术选型，我个人的建议是：如果业务里大量使用了Oracle的存储过程、包、触发器，而且你没有精力做深度改造，那金仓和达梦都值得重点评估，它们对Oracle语法的兼容做得最用工；如果业务是互联网风格、数据量大、并发高、需要水平扩展，那OceanBase这类分布式数据库更对路；如果你团队本身就熟悉PostgreSQL，那选金仓或openGauss的上手成本会最低，因为运维习惯、监控指标、调优参数都很接近。

当然，没有绝对的好坏，只有合不合适。我在实际项目中见过有团队用OceanBase跑传统报表系统，结果发现存储过程支持不够完善，反而被拖慢了进度。所以选型之前，一定要把业务SQL的复杂程度、数据量级、团队技术栈这三个因素想清楚。

2. 上手前必须知道的三个底层设计——兼容、大小写与事务

在你真正敲下第一条SQL之前，我建议先花十分钟理解金仓的三个底层设计。这三个设计如果不提前搞清楚，后面几乎每一步都会踩坑，尤其是你以前只用过MySQL的话。

2.1 兼容模式：Oracle 兼容还是 PostgreSQL 兼容，怎么切换

金仓最核心的一个概念叫“兼容模式”。什么意思呢？因为它的内核是PostgreSQL，但对外又要兼容Oracle，所以它提供了一种机制，让同一个实例在启动、创建数据库的时候，可以声明自己“更偏向谁”。

具体到操作层面，你在安装初始化数据库的时候，会有一个参数来指定兼容模式，比如-m Oracle或者初始化后通过数据库模板创建不同兼容模式的库。一旦数据库创建完成，它就会按照对应的兼容规则来解析SQL。

举个例子，在Oracle兼容模式下，SELECT SYSDATE FROM DUAL就能正常工作，空字符串会被当成NULL处理，ROWNUM分页也支持；而在PostgreSQL兼容模式下，这些Oracle特有的语法就可能报错，你得用CURRENT_TIMESTAMP、LIMIT/OFFSET这种PG写法。

为什么这个设计重要？因为我在实际项目里见过太多次“数据库起来了，但是业务SQL大面积报错”的情况，最后排查下来发现是兼容模式搞错了。所以拿到一套新的金仓环境，第一件事就是确认当前数据库的兼容模式，不要想当然。

2.2 大小写敏感：被坑最多的地方

大小写敏感这个问题，是我认为金仓新手最容易被坑、也最不好排查的一个点，必须单独拿出来说。它的规则其实完全继承了PostgreSQL：不带双引号的标识符会被自动折叠成小写，带双引号的标识符则严格区分大小写。

这带来一个很实际的后果：你在Oracle里有一张表叫EMP，习惯性写SELECT * FROM EMP，在Oracle里没问题；但如果在金仓里用PG默认行为，EMP会被解析成小写的emp，如果你的表在创建时是带双引号的"EMP"，那这条SQL就会报“表不存在”。

更麻烦的是反向情况。有时候你用可视化工具建表时，工具默认加上了双引号，表名变成了"User"这种驼峰式。然后你写SQL时又没加双引号，查来查去就是查不到数据。这种坑，初学者能折腾一晚上。

我的建议是：在建表和写SQL时统一规范，全部使用小写加下划线的命名方式，并且永远不要依赖双引号。这样既能在金仓上跑通，也能在MySQL、PostgreSQL上跑通，省去很多不必要的麻烦。

2.3 事务、MVCC与锁：金仓的并发控制是怎么工作的

金仓的事务和并发控制机制，基本沿用了PostgreSQL那套MVCC（多版本并发控制）设计。简单说，读操作不会阻塞写操作，写操作也不会阻塞读操作，每个事务看到的数据快照由事务ID来决定。这种设计在大并发场景下表现很好，也是PG系数据库的一贯优势。

但MVCC不是银弹，它和锁机制是配合使用的。你在做UPDATE或DELETE时，仍然会触发行级锁；在做ALTER TABLE、VACUUM等操作时，可能会触发表级锁。如果不注意事务的提交顺序，就可能出现锁等待甚至死锁。

我给你的实操建议是：第一，事务尽量保持短小，不要在一个事务里做大量耗时的查询和更新；第二，在代码层面要避免“先查后改”的间隙锁竞争，比如先SELECT ... FOR UPDATE再更新，就一定要保证所有并发路径都按同样的顺序加锁；第三，遇到锁等待问题时，可以通过金仓的系统视图去查看是哪个会话卡住了谁，这个我后面在常见问题部分会详细讲。

3. 5分钟跑起一个金仓实例：Docker 部署与客户端连接

前面讲了一堆理论，接下来进入动手环节。我相信大部分人第一次接触金仓，最迫切的需求就是“赶紧给我一个能用的环境”。那么我这里直接推荐你用Docker，这是目前学习金仓成本最低、速度最快的方式。

3.1 为什么推荐用 Docker 装金仓

正常安装一个数据库，你至少需要搞定操作系统版本、依赖库、内核参数、安装目录规划、用户权限等一堆事情。金仓本身是支持主流Linux发行版直接安装的，但如果你只是为了学习，或者想做课程设计，完全没必要这么折腾。

Docker的优势就三条：快、干净、可复现。一条docker pull就能把镜像拉下来，一条docker run就能启动一个实例，不用了直接docker rm删掉，一点不污染宿主机。而且整个安装过程是可脚本化、可重复的，下次换台电脑，同样的命令再跑一遍就能复现同样的环境。

当然，我要提醒一句：生产环境不要用Docker跑数据库。不是说容器技术不行，而是生产数据库对IO性能、网络延迟、持久化策略的要求非常苛刻，容器化会给运维增加额外复杂度。学习、开发、测试用Docker没问题，生产环境还是规规矩矩用物理机或云主机安装。

3.2 Docker 部署实操：拉镜像、启动容器、初始化参数

以我实际用过的流程为例，整个过程只需要几步。需要说明的是，因为官方镜像仓库在不同时期的地址和标签会调整，我这里给的命令是示意性的，你实际操作时以官方文档里的镜像地址为准。

# 1. 拉取镜像（具体镜像名以官方文档为准） docker pull kingbase/kingbasees:v8 # 2. 查看镜像是否拉取成功 docker images # 3. 启动容器，映射端口、设置数据目录，并指定密码 docker run -d \ --name kb8 \ -p 54321:54321 \ -e KINGBASE_USER=system \ -e KINGBASE_PASSWORD=your_password \ -e KINGBASE_DB=testdb \ -v kb_data:/home/kingbase/userdata \ kingbase/kingbasees:v8 # 4. 查看容器启动日志 docker logs -f kb8

这里面有几个参数需要解释一下。端口映射-p 54321:54321，金仓的默认端口就是54321，跟MySQL的3306完全不是一个路子，很多新手第一反应是用5432去连，结果连不上，这个要注意。KINGBASE_USER我设置成了system，这是金仓的超级管理账号，相当于Oracle的SYS或者PostgreSQL的postgres。KINGBASE_DB可以指定初始化时自动创建的数据库名，方便后面直接用。

如果你在自己电脑上执行完上面的步骤，发现容器一直处于Restarting状态，大概率是端口冲突或者宿主机目录权限问题。查看docker logs是最直接的排查手段，不要瞎猜。

3.3 客户端连接：DBeaver、KStudio 与 JDBC

数据库起来了，总得有个工具去连它。金仓官方提供了一个图形化管理工具叫KStudio，类似Navicat的体验，如果你是做课程设计，用这个工具点来点去就能完成很多操作。但说实话，我更推荐你用DBeaver，因为它是开源的、跨平台的，而且对金仓这类国产数据库的支持相当好。

用DBeaver连金仓的时候，连接URL一般是这样：

jdbc:kingbase8://127.0.0.1:54321/testdb

驱动类名是com.kingbase8.Driver。DBeaver首次连接时需要下载驱动包，你可以直接选它内置的Kingbase驱动，如果找不到，就手动把金仓安装目录下的JDBC驱动jar包加进去。

如果你是用Java开发，在pom.xml里引入金仓的JDBC驱动后，配置数据源的代码大概是这样的：

String url = "jdbc:kingbase8://127.0.0.1:54321/testdb"; String username = "system"; String password = "your_password"; Connection conn = DriverManager.getConnection(url, username, password);

连接这块最容易出现的错误有两个。第一个是端口写错，默认是54321，不是5432。第二个是驱动类名写错，com.kingbase8.Driver中间的kingbase8是不带后缀的，别画蛇添足。把这两点记住了，连接基本一次通。

4. 日常开发中最高频的操作：建库建表与增删改查

环境跑通了，接下来就是要真正用起来。这一节我按日常开发里最常用到的操作来梳理，包括建库建表、增删改查、分页查询，以及课程设计里常见的一些需求点。

4.1 建库建表与数据类型选择

在金仓里建库最常用的语句有两种写法。第一种是在SQL编辑器里执行CREATE DATABASE：

CREATE DATABASE school_db WITH OWNER = system ENCODING = 'UTF8';

第二种是用DBeaver这类工具右键“新建数据库”，然后在弹窗里设置名称、字符集、兼容模式。我建议你把字符集指定为UTF8，否则后面导入中文数据时容易出现乱码。

建表就没有太多特殊之处，但数据类型这块是新手问得最多的。金仓为了兼容Oracle，提供了很多带Oracle风格的类型别名，比如VARCHAR2等价于VARCHAR，NUMBER等价于NUMERIC，DATE在Oracle兼容模式下可以带时间。下面是我常用的一种建表方式：

CREATE TABLE student ( id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, student_no VARCHAR(32) NOT NULL UNIQUE, name VARCHAR(64) NOT NULL, gender CHAR(2), birth_date DATE, score NUMERIC(5,2), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

这里用到了自增列，金仓完全支持GENERATED BY DEFAULT AS IDENTITY，这比手写序列省事多了。如果你是从Oracle迁移过来的代码，也可以直接用CREATE SEQUENCE加触发器的方式，金仓同样支持。

4.2 增删改查与分页查询的三种写法

增删改查的基础语法跟标准SQL一致，我就不逐条展开了，重点讲讲分页查询，因为这是最常遇到的“语法分叉点”。

在PostgreSQL兼容模式下，标准写法是：

SELECT * FROM student ORDER BY id LIMIT 10 OFFSET 20;

在Oracle兼容模式下，可以用ROWNUM：

SELECT * FROM ( SELECT t.*, ROWNUM AS rn FROM student t ) WHERE rn BETWEEN 21 AND 30;

如果你在Oracle兼容模式下硬写LIMIT语法，很有可能报错。所以分页这条SQL你最好根据数据库模式提前确认，避免运行时才发现。我个人建议能统一就统一用标准SQL或LIMIT/OFFSET，这样代码将来迁移到MySQL、PostgreSQL都更方便。

至于JOIN查询，金仓对JOIN的支持很完善，INNER JOIN、LEFT JOIN、RIGHT JOIN、CROSS JOIN都没问题。我记得热搜词里有“MySQL JOIN含义”，其实放到金仓上理解完全一样——JOIN就是把两张表按某个关联条件组合成一张虚拟结果集，ON子句里的条件就是两张表之间的匹配规则。不要被不同数据库的方言吓到，核心原理是同一个。

4.3 课程设计里怎么用金仓加分

如果你是学生，手里正拿着一份数据库课程设计题目，我建议你有策略地用金仓来“叠buff”。常规做法是用MySQL或者Access做一个学生管理系统，但如果你换成金仓，完成同样的功能，在老师的眼里完全是两个档次的作品。

具体可以这么做：用北风数据库（Northwind）作为参考，设计一套销售管理或者库存管理的表结构，在金仓里建出几十张表，然后把数据导入进去。接着用DBeaver画ER图，用金仓的视图、存储过程、触发器实现几个复杂的业务逻辑，比如库存不足自动预警、订单总价自动计算。最后写一份设计文档，说明你是如何用金仓的事务机制保证数据一致性的，以及你是如何排查死锁的。

这几个点一做出来，课程设计报告会显得非常扎实。而且金仓在校园里的正版授权通常很容易申请，用起来没有版权风险。

5. 从 Oracle / MySQL 迁移到金仓——实战思路与同步方案

很多人接触金仓，不是主动的，而是被项目逼的，比如“这个系统要从Oracle换到金仓”。那么迁移这个话题就绕不开。这一节我结合自己实际帮人做过迁移的经验，讲一套相对完整的流程。

5.1 迁移前评估：哪些东西会“水土不服”

迁移前先做个“体检”，把目标库里的对象盘点清楚。通常来说，普通表、索引、约束、视图这类对象迁移起来比较顺利，因为金仓对标准SQL的支持很强。但下面这几类要特别留意：

• 存储过程、函数、包：Oracle里的PACKAGE是一个大问题，金仓虽然做了很多兼容，但如果你用了复杂的包内公共变量、重载函数，就可能要手工改写。
• 数据类型：Oracle的NUMBER长度不指定时，金仓可能解析成NUMERIC，但有些精度差异会导致数据溢出或取整错误。
• 序列：Oracle的SEQUENCE.CURRVAL、NEXTVAL语法和金仓不完全一致，SQL脚本里要批量替换。
• 伪列：ROWNUM、ROWID这些要分场景处理，尤其是ROWID，金仓没有完全等价的实现。
• 空字符串语义：Oracle里''等于NULL，而PostgreSQL语义里它们是不同的，这会让已有数据的查询结果出现差异。

所以在写迁移方案时，我建议你先导出一份全量SQL脚本，静态扫描一遍里面的关键字，把不兼容的点先标出来，再动手迁移。这一步能省掉后面90%的麻烦。

5.2 用官方迁移工具和 Kettle 完成数据搬迁

金仓官方提供了一套数据迁移工具，通常叫KDTS或迁移助手之类。用官方工具的好处是，它会自动做很多语法转换和类型映射，比如把Oracle的VARCHAR2转成VARCHAR，把SYSDATE换算成金仓的写法。工具操作起来一般是图形界面的，三步走：选择源库、选择目标库、启动迁移任务。

如果你面对的是MySQL、SQL Server等其他数据源，或者你想用更通用一点的ETL工具，那用Kettle是很好的选择。Kettle的背景就是开源的ETL工具，里面提供了金仓的插件，可以很方便地配置源和目标。

无论用哪种工具，迁移完成后一定要做“数据对账”，不要只看迁移日志显示成功就完事。对账的办法很简单：每张表分别查一下源库和目标库的总行数，抽样核对几条关键数据，再跑一遍主外键约束校验。我见过不止一次“工具显示迁移成功，但某张表少了十几万行”的情况，就是因为中途有脏数据直接跳过了。

5.3 数据库同步工具：增量同步怎么配

除了全量迁移，还有一种常见需求是“数据库同步”，比如主库到备库、生产库到分析库、旧库到新库的增量同步。金仓生态里有专门的数据同步工具，原理基本是基于日志解析或者触发器。

如果你要配置增量同步，大致思路是：在源库开启归档模式，然后同步工具实时读取归档日志或者在线日志，把变更解析出来，再应用到目标库。整个过程不需要修改业务代码，对业务的影响很小。

配置同步时要注意几个点：两端的字符集要一致，否则中文容易乱码；源库和目标库的表结构要完全一致，否则同步任务很容易中断；同步过程中一定要在监控页面上盯住延迟量，如果延迟持续变大，说明同步节点的性能不够或者有大事务卡住了。

另外，如果你在搜索时看到“dbx数据库工具”这个词，它也是一类数据库管理工具，在某些环境下作为客户端连金仓也可以用。但我个人主力还是用DBeaver和官方KStudio，功能稳定，遇到问题也好搜资料。

6. 面试题高频考点：从金仓出发把数据库原理吃透

老实说，大部分公司面试不会单独考“人大金仓”这个产品的API级细节，他们想考的是你通过使用金仓，有没有真正理解数据库的底层原理。所以这一节我把面试里最高频的考点和金仓结合起来讲，帮你做到举一反三。

6.1 面试官问“你用过什么数据库”时，怎么讲金仓

如果简历上写了金仓，面试官大概率会追问“金仓和MySQL/Oracle有什么区别”。这时候最忌讳的回答是“金仓是国产数据库，支持信创，所以我们用了”，太单薄了。更好的思路是三段式：

第一段说项目背景：比如“这个系统原本是Oracle的，因为国产化要求需要迁移到金仓，我负责了整个迁移过程中的SQL适配和部分存储过程改写”。

第二段说具体细节：挑一两个你真正做过的事情，比如“我当时处理了上百个带ROWNUM的分页查询，统一改写成了金仓兼容模式支持的写法”，或者“排查过一个死锁问题，通过金仓的锁视图定位到并发更新同一行数据的两个会话”。

第三段说沉淀和思考：比如“通过这次迁移我理解了Oracle和PostgreSQL在空字符串、大小写敏感、序列上的差异，也意识到国产数据库不是简单替代品，而是需要结合业务做适配”。这样一讲，既体现了动手能力，又体现了总结能力，面试官会很有好感。

6.2 基于金仓的数据库原理高频题

下面几个题是我在面试别人时经常问的，也是大家准备面试时最容易答得浅的问题。

索引这块，问最多的是“为什么索引能提高查询速度”。你可以结合金仓的B+树索引来讲：数据量大的时候，全表扫描是线性开销，而B+树通过多级分支把查找路径缩短到对数级别，所以索引能大幅减少磁盘IO。但索引不是越多越好，因为每次增删改都要维护索引，索引太多会拖慢写入性能。在金仓里，判断一条SQL有没有走索引，可以用EXPLAIN ANALYZE去看执行计划。

事务隔离级别和MVCC也是高频题。金仓默认的隔离级别是读已提交，这点跟Oracle默认一样，但跟MySQL默认的可重复读不一样。如果面试官问“RR和RC的区别”，你可以顺着金仓的MVCC实现讲：MVCC让读操作不阻塞写操作，但不同隔离级别下，一个事务能看到哪些已提交版本、是否出现幻读，规则是不同的。

死锁几乎是必考题。面试官通常会问“死锁产生的四个条件是什么，怎么避免”。四个条件你一定背过：互斥、占有且等待、不可剥夺、循环等待。在金仓里，最常见的死锁是两个事务以不同的顺序更新同一组数据。比如事务A先更新表1再更新表2，事务B先更新表2再更新表1，当它们彼此持有对方需要的锁时，死锁就发生了。解决办法也很经典：让所有事务都按固定的顺序访问资源，同时把事务做得尽量短小。

SQL优化这块，最常见的问题是“一条慢SQL怎么排查”。我的排查顺序是：先用EXPLAIN ANALYZE看执行计划，确认有没有走索引；再看是不是类型隐式转换导致索引失效；再看表数据量是不是太大需要分页或者归档；最后才考虑改SQL结构，比如把子查询改成JOIN。

6.3 KCA/KCP 认证与学习路径

如果你对金仓有兴趣，想系统学习，可以关注它官方的认证体系。入门级是KCA（Kingbase Certified Associate），高级是KCP（Kingbase Certified Professional）。KCA主要考数据库的基础知识、安装部署、日常运维和SQL使用，KCP会涉及高可用、备份恢复、性能调优这些更深的内容。

网上有热心网友整理的KCA考试题库在线练习资源，也有不少人在博客里分享考试心得。我个人的看法是，题库刷一刷有助于通过考试，但真正有价值的是你自己去操作环境，把题库里提到的场景亲手跑一遍。认证这玩意儿在招聘里不会起决定作用，但在同等条件下，有“国产数据库认证”确实是个加分项，尤其对准备进国企、政务类项目的同学来说。

7. 常见问题与排查技巧实录

最后把这几年积累的、跟金仓相关的高频问题和排查手段整理成一份速查表，希望你在遇到类似问题的时候能少走弯路。

7.1 连接失败与驱动报错速查

连接池报错是另一个常见问题。Java项目里用HikariCP或者Druid连金仓时，有时候会出现连接被断开的报错，这往往是因为数据库的idle_in_transaction_session_timeout或者网络层空转超时把连接关了。这时候要在连接池配置里加上测试连接、空闲检测相关的参数，保证连接池能自动回收失效连接。

7.2 死锁和锁等待的排查办法

有一次线上系统突然变慢，业务日志里全是“deadlock detected”的报错。我当时的第一步是找到死锁会话和阻塞会话，用到的语句大致是这样的：

SELECT pid, state, wait_event_type, wait_event, query FROM sys_stat_activity WHERE state <> 'idle';

通过这个查询，我看到两个会话都在等待同一种锁，一个在做UPDATE，一个在做DELETE，而且操作的是同一张表的相邻行。随后我进一步查了锁信息视图，找到了锁冲突的具体对象，然后让业务方把这两个操作的顺序统一，问题就解决了。

排查死锁有一个很重要的原则：先止血，再根治。止血就是找到死锁会话后SELECT pg_terminate_backend(pid)把它杀掉，让业务先恢复；根治才是去改代码逻辑。不建议在没有任何分析的情况下反复重启数据库，那是治标不治本。

7.3 性能慢的排查思路

金仓慢SQL的排查思路跟PostgreSQL基本一致。第一板斧就是EXPLAIN ANALYZE，看执行计划里是不是出现了“Seq Scan on 大表”，如果是，就说明没有走索引。

EXPLAIN ANALYZE SELECT * FROM orders WHERE create_time >= '2024-01-01' AND status = '1';

第二板斧是检查索引有没有失效。常见原因包括：条件列上有函数运算、隐式类型转换、前导模糊查询等。比如WHERE name LIKE '%张%'这个条件，B+树索引基本帮不上忙，可以考虑全文索引或者其他方案。

第三板斧是看数据库参数和硬件资源。如果CPU和内存都没到瓶颈，但SQL就是慢，很可能需要调整金仓的内存参数，比如shared_buffers、work_mem。这些参数在默认值下往往比较保守，压测之后适当调大能带来很明显的性能提升。

还有一个很多人忽略的点：统计信息不更新会导致优化器选错执行计划。频繁增删改的大表，记得定期执行ANALYZE，在PostgreSQL系数据库里这几乎是“免费”的性能优化手段。

最后再分享一个我个人的小习惯：在金仓上做任何批量操作，比如几百万行的数据更新，千万不要开成一个大事务一把梭。把数据按主键范围或者时间范围拆成小批次，每个批次单独提交，不仅能减少锁竞争，还能避免中途失败导致全部回滚。这个习惯让我在无数次数据订正和迁移中稳住了局面，希望你也能用上。