企业官网建设流程全解析

人大金仓这个数据库，这几年在国产数据库圈子里热度一直很高，尤其是随着信创项目的铺开，越来越多的业务系统从Oracle、MySQL迁移到KingbaseES上。我自己也陆续在好几个项目里接触过它，从最初的Docker部署验证，到后面的生产环境调优、备份恢复、数据迁移，踩过的坑和总结的经验都不少。这篇东西就把我对人大金仓的理解整理成一整套可落地的知识体系，从它是一个什么东西，到怎么快速部署一套环境，再到日常运维中的核心参数、高频SQL、迁移适配、备份恢复和问题排查。

这套总结适合几类人看：正在做信创适配的研发和运维人员，准备从Oracle/PostgreSQL切换到金仓的DBA，以及那些只是想在本地快速拉一套数据库做学习和验证的开发者。我会尽量把关键原理讲明白，里面涉及的配置和命令都是我实际验证过可以直接用的，不是那种抄官网文档的堆砌。读完你至少能做到：独立部署一套金仓环境、理解它的存储和进程结构、写对日常运维命令、在遇到迁移和性能问题时有个清晰的排查方向。

1. 人大金仓到底是什么——先建立整体认知

很多人在刚接触人大金仓的时候，第一反应是“又一个国产数据库”。但实际用起来你会发现，它跟某些只是换了个壳的国产数据库不一样，金仓和PostgreSQL之间有着非常深的血缘关系，弄懂这一点，后续学习才会事半功倍。

1.1 人大金仓的来历：从PG到KingbaseES的血缘关系

人大金仓（KingbaseES，通常简称KES）是由中国人民大学一批数据库领域的专家主导研发的，后来成立了北京人大金仓信息技术股份有限公司来商业化运作。它的内核在早期版本里大量汲取了PostgreSQL的设计思想，发展到现在，KingbaseES V8在SQL语法、存储引擎、事务机制、备份恢复这些核心能力上，依然能看到PG的影子。

这个血缘关系带来一个直接的好处：如果你懂PostgreSQL，上手金仓的很多基础操作几乎是无缝切换。比如psql对应的命令行工具是ksql，pg_dump对应sys_dump，pg_ctl对应sys_ctl，连默认的端口号习惯和配置文件的组织方式都很接近。反过来，如果你是一个只会Oracle的DBA，也不用慌，金仓提供了Oracle兼容模式，很多Oracle的PL/SQL语法、数据类型、系统视图都能直接跑，这也是它在金融、政务、能源这些存量Oracle系统迁移中能站住脚的核心原因。

说到兼容模式，这是金仓区别于普通国产数据库的一个重要设计。KES在初始化实例的时候，可以通过配置选择兼容Oracle还是兼容PostgreSQL的模式，也能在会话级别动态切换。虽然做不到100%的Oracle兼容，但常用的包、函数、存储过程语法，覆盖度已经很高了。我在实际迁移项目里，有一批老的Oracle PL/SQL存储过程，基本上是原封不动迁移过去的，只有少数几个冷门用法需要手工改写。

1.2 版本差异与授权形态

人大金仓目前市面上主要流通的是KingbaseES V8版本，内部又分为V8R3、V8R6等小版本系列，R6是近几年主推的版本，对Oracle的兼容性更好，也引入了更多企业级特性。V8R3在某些存量环境里还有，但新项目建议直接用V8R6。

授权这块要特别提一下。金仓的授权模式是按CPU核数来授权的，跟Oracle的License概念有点像，而不是像MySQL那样按实例随便装。所以在生产环境规划的时候，评估清楚你每个节点的CPU核数很重要。好在金仓提供了比较宽松的开发试用授权，个人学习或者项目预研，申请一个开发版就能用，激活和配置的流程也不复杂，具体可以走官方渠道申请，这里就不展开讲了。

1.3 它和PostgreSQL到底像不像

我在技术社区里经常看到有人争论“金仓是不是PG套壳”。这个说法既对也不对。说它像，是因为内核层面确实大量复用了PG的架构设计，甚至早期版本里很多代码就是从PG衍生出来的，这是公开的技术事实。说它不完全是，是因为人大金仓在PG基础上做了大量的企业级改造，包括更贴近Oracle的语法兼容层、更复杂的权限管理、高可用和读写分离组件、以及针对国内项目习惯做的图形化管理工具和迁移工具。

所以我的建议是：如果你要深入学金仓，不需要从零开始啃，先吃透PostgreSQL体系结构，再去对照着看金仓的差异点，这个路径的效率最高。如果你的事务里只需要“把金仓用起来”，那先掌握本文后面几章的内容，应付日常开发运维绰绰有余。

2. 5分钟用Docker拉起一套金仓环境

学习任何一个数据库，最快的路径永远是先把环境跑起来，然后对着文档一点点试。金仓的安装包虽然也支持直接在物理机或者虚拟机上装，但如果你只是用来学习、做功能验证、或者跑自动化测试，用Docker是最省事的。这也是最近“人大金仓数据库docker”搜索热度居高不下的原因——大家都想三分钟搞定一个学习环境。

2.1 镜像获取与版本选择

金仓提供了官方的Docker镜像，你可以从官方镜像仓库拉到带版本号的镜像。这里要说一句，镜像的tag选择比较重要，我建议优先选类似v8r6这种带明确版本标识的，不要选latest，因为latest有时候指向的是最新开发版，行为跟稳定版可能有差异，复现问题的时候容易把自己坑了。

操作很简单，先把镜像拉下来：

docker pull kingbase/kingbasees:v8r6

拉完之后确认镜像已经就位：

docker images | grep kingbase

注意，不同渠道的镜像仓库地址和命名可能有差异，有的私有镜像仓库可能需要先做登录才能拉取。如果你手里有金仓官方给的内网镜像地址，直接替换pull后面的地址就行。

2.2 docker run参数里那些容易被忽略的细节

镜像拉下来之后，启动命令看起来很简单，但有几个参数直接决定了你的容器能不能被正常连接和数据能不能持久化，这里必须逐一说清楚。

我这边的标准启动命令长这样：

docker run -d \ --name kingbase-test \ -p 54321:54321 \ -e ENABLE_CIF=true \ -e DB_USER=system \ -e DB_PASSWORD=123456 \ -e DB_MODE=oracle \ -v /data/kingbase:/home/kingbase/kingbase/data \ kingbase/kingbasees:v8r6

逐条解读一下：

• -p 54321:54321：金仓的默认端口是54321，不是3306也不是5432，这个特别容易记混。宿主机端口你可以随意改，比如-p 154321:54321，容器内端口保持54321不动。
• -e ENABLE_CIF=true：CIF是大小写敏感参数。如果设为true，说明数据库对大小写敏感，这是为了兼容Oracle的行为。Oracle迁移过来的库通常要开这个选项，因为Oracle里表和字段名默认是大写的，PG体系默认是大小写不敏感的，不处理的话迁移后会有一堆坑。
• -e DB_USER=system：金仓的超级管理员默认是system用户，不是PostgreSQL里的postgres，这点跟PG不同，跟Oracle倒是有点像。
• -e DB_MODE=oracle：指定默认的兼容模式为Oracle，如果你主要跟PG语法打交道，可以改成pg，但做信创项目大部分人是冲着Oracle迁移来的，所以这里直接设成oracle。
• -v /data/kingbase:/home/kingbase/kingbase/data：这是数据持久化挂载。容器内部金仓的数据目录在这个路径下，映射到宿主机，是为了防止容器删了之后数据全丢。生产上做容器化部署时这个目录建议用单独的存储盘，不要和系统盘混在一起。

启动之后等几十秒，可能是因为初始化数据目录需要点时间，用docker logs跟踪一下状态：

docker logs -f kingbase-test

看到类似“database system is ready to accept connections”这样的日志，说明数据库已经起来了。

2.3 首次启动的初始化与连接验证

容器起来了，下一步是验证能不能正常连接。进入容器内部用ksql连一下：

docker exec -it kingbase-test bash su - kingbase ksql -U system -d test

这里有个常见的坑：金仓默认有一个test数据库，而且很多版本的镜像里都已经建好了，直接用就行。如果你没找到test库，可以用-d postgres先连进去看看，再自己CREATE DATABASE。

如果是在宿主机上通过外部工具连接，比如用DBeaver或者Navicat连接，主机IP填容器的宿主机IP，端口填54321，用户名填system，密码填你传的那个DB_PASSWORD。我这里用Navicat实测过，选PostgreSQL驱动就能连上，但需要注意连接参数里可能要显式设置兼容模式才能让一些查Oracle系统视图的SQL正常执行。

提示：Docker启动金仓主要用于开发和学习，生产环境建议还是用官方推荐的物理机或虚拟机方式部署。容器方案在性能、网络、存储管理上都有额外损耗，遇到IO瓶颈时排查成本会更高。

3. 体系结构与核心参数——DBA必须懂的那层皮

把环境跑起来之后，接下来要往深里走一点。一个数据库能不能用好，取决于你对它的体系结构了解多少。金仓的体系结构跟PG高度相似，但也有自己的一些差异化设计。这一章我会把进程结构、存储结构、内存结构和关键配置文件拆开讲。

3.1 进程结构与内存区域划分

金仓的实例启动后，默认有几个核心后台进程在跑，我列一下主要的部分：

• Kingbase主进程：负责接收客户端连接请求，为每个连接分配一个独立的会话进程。你可以理解成酒店前台，所有客人进门都得先跟它打交道。
• 后台写进程（BgWriter）：负责把共享缓冲区的脏页定期写回磁盘。这个机制直接关系到刷盘性能，如果脏页积累太多，会因为checkpoint集中写盘导致IO抖动。
• WAL日志写进程（WALWriter）：事务提交时先写WAL日志，保证崩溃恢复的时候数据不丢。这跟Oracle的redo log是一个逻辑。
• 检查点进程（Checkpointer）：定期做检查点，把脏页刷盘并更新控制文件。检查点频率和WAL大小关系密切，设置不当要么恢复时间过长，要么日志切换过频。
• 统计信息收集进程：收集表级和索引级的统计信息，给查询优化器做决策参考，这也是为什么新装完库要做analyze的原因。
• 归档进程：如果开启了归档模式，它负责把WAL日志复制到归档目录，是备份恢复方案中不可或缺的一环。

内存方面，金仓主要分几块：共享缓冲区（类似Oracle的SGA里的buffer cache）、WAL缓冲区、以及每个会话自己的私有内存区（类似PGA）。这个结构决定了你在调优的时候要分两头看：共享缓冲区的命中率决定大部分读请求是不是在内存里就完成了，而会话私有内存决定排序、哈希连接这些操作要不要落到临时文件。

3.2 存储结构和数据目录

金仓的数据目录在安装时由initdb初始化，Docker环境下就是上面说的/home/kingbase/kingbase/data。看一个典型的数据目录结构，你会觉得它跟PG几乎一模一样：

• base/：实际的用户数据库目录，每个数据库有一个子目录，数据库OID就是目录名。
• global/：存放全局性的系统表，比如数据库名和OID的映射关系。
• pg_wal/（等价于PG版本里的pg_wal）：存放WAL日志文件。
• postgresql.conf：实例级参数配置文件，对应金仓里面的配置文件名叫kingbase.conf，但很多参数名字跟PG一致。
• pg_hba.conf：客户端认证配置文件，控制谁能连、怎么连。
• PG_VERSION：记录版本信息，迁移数据目录的时候这东西不能丢。

我在第一次看金仓数据目录的时候，直接当PG来处理，后面用起来果然没出什么问题。所以在排查一些莫名其妙的“表不存在”、“无法连接”问题时，先看看数据目录权限和配置文件，往往能很快定位。

3.3 关键配置参数解读

配置参数这块，是DBA调优的主战场。金仓的很多参数在命名和含义上都跟PG对齐，但也有自己的扩展。几个关键参数我单独拎出来讲：

shared_buffers：共享缓冲区大小，初始默认值通常比较保守，生产环境建议调整为物理内存的20%~25%。它不是越大越好，因为还要给操作系统页缓存留空间，而且共享缓冲区太大，会让WAL写进程和后台写进程的刷盘压力增大。

work_mem：每个排序操作、哈希操作可用的内存。这个参数要注意，它是按操作分配的，不是按会话分配的。如果一个会话里同时有多个排序操作，每个都会占用一份work_mem空间。默认值偏小，数据量大的查询容易落临时文件，但调得太大又可能导致并发场景下内存被吃完。经验做法是先小步调大，观察峰值内存再决定。

max_connections：最大连接数。金仓的连接模型是“一个连接一个进程”，连接数设置太高时，切换上下文和内存开销会很明显。很多系统问题不是数据库本身慢，是连接数撑爆了，配合连接池使用才是正解。

archive_mode / archive_command：归档相关参数。做备份恢复、流复制高可用的时候必须开启，如果只是单机跑业务，可以关掉省点IO损耗。

下面是一个我常用的基础调优配置片段，假设物理内存32G，并发200：

shared_buffers = 8GB effective_cache_size = 24GB work_mem = 64MB maintenance_work_mem = 1GB max_connections = 500 checkpoint_timeout = 15min max_wal_size = 8GB min_wal_size = 2GB

这些参数不是固定答案，但至少是一个可用的起步值。我始终强调一句话：不要抄网上的配置直接上生产，一定要结合自己的业务SQL和数据量特点做压测验证。

4. 日常运维中的高频操作与SQL避坑

环境跑通了，参数也调了，接下来要做的事情就是日常使用。这一章我会把日常运维中最常用到的管理命令、最容易踩的SQL和兼容性坑都梳理一遍，这些基本上都是我在真实项目里反复用到的。

4.1 常用管理命令

金仓的常用管理命令跟PG保持高度一致，熟悉psql的人几乎零成本切换。下面这些命令是我在工作中用得最多的：

启动和停止实例：

# 启动（在kingbase用户下执行） sys_ctl -D /home/kingbase/kingbase/data start # 停止 sys_ctl -D /home/kingbase/kingbase/data stop -m fast # 查看状态 sys_ctl status

连接数据库：

ksql -U system -d test -p 54321

常用元命令，在ksql里执行：

\l -- 列出所有数据库 \dt -- 查看当前schema下的所有表 \d 表名 -- 查看表结构 \du -- 查看用户和角色 \df -- 查看函数列表 \conninfo -- 查看当前连接信息

查看当前数据库会话和锁：

SELECT pid, usename, state, wait_event_type, wait_event, query FROM pg_stat_activity;

这个视图可以说是排查性能问题的一号选手，我后面会反复提到它。任何数据库卡顿、锁等待的现象，第一步永远是看这个视图，查状态、查等待事件、查执行中的SQL。

切换schema和兼容模式：

SET search_path TO myschema; SHOW compatible_mode; -- 查看当前兼容模式

4.2 数据类型与自增列的坑

从Oracle迁移到金仓的人，最先遇到的一批坑基本都集中在数据类型的映射上。金仓为了兼容Oracle，做了不少类型映射，但写代码的人如果不注意，还是会踩雷。

自增列是第一个大坑。Oracle里的自增是靠SEQUENCE + TRIGGER实现的，PG体系里常用SERIAL类型或者IDENTITY列。金仓的Oracle兼容模式里，用GENERATED BY DEFAULT AS IDENTITY或者直接建SEQUENCE配合DEFAULT nextval(...)都可以。但你不能在Oracle习惯下写了一个触发器，又指望它跟金仓的自动生成机制不冲突。

我最推荐的做法：

CREATE TABLE user_info ( id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, name varchar(100), create_time timestamp default current_timestamp );

这个写法语义清晰，不需要额外维护sequence和trigger，执行insert的时候如果不指定id列，会自动生成一个自增值。但注意，如果从Oracle迁移过来，原来已经建好的sequence和trigger不会自动消失，需要判断是否重复生成值。

空字符串和NULL，这是另一个高频坑。Oracle里空字符串和NULL是等价的，直接把空串插入到NOT NULL字段会报错，因为它在Oracle里就是NULL。但金仓在Oracle兼容模式下，对空字符串的处理跟Oracle不一样，它保留了一个空字符串的独立语义，导致老代码里类似WHERE col = ''的写法可能查不到数据，而原来在Oracle里这个条件等价于WHERE col IS NULL。

这个问题的规避策略是：迁移数据的时候统一做空值清洗，让业务侧约定好“到底用空串还是用NULL”，不要两边混用。

日期类型也要注意。Oracle的DATE包含时分秒，而PG体系里的DATE只有日期，时间要用TIMESTAMP。金仓在Oracle兼容模式下会把DATE映射成带时间的类型，但如果你自己建的库里session兼容模式是pg，那DATE就不带时间。我遇到过测试环境好好的、生产环境一跑，日期查出的结果少了时间部分，排查到最后就是两个库的兼容模式不同。

4.3 兼容性开关与迁移工具

金仓的Oracle兼容不是靠某个全局开关一键搞定的，它分了库级、schema级和会话级多个维度。最简单的做法是在建库和启动实例时确定好兼容模式，然后尽量保持整个生命周期内不要变来变去。

DB_MODE=oracle这种环境变量在Docker方式下设置的就是库默认兼容模式。

迁移工具方面，金仓官方提供了一个图形化迁移工具，封装的迁移流程大致是：连接源库（Oracle/MySQL/SQL Server）→ 采集元数据 → 转换对象定义（表结构、索引、约束、视图、存储过程等）→ 全量/增量迁移数据 → 对比校验。我实测下来，对于常规的表、索引、主外键约束，这个工具迁移成功率很高；但存储过程这些逻辑复杂对象，它转换出来的代码不一定能直接跑通，还是需要人工手工修正。

提示：迁移之前先在测试环境跑一遍全流程，记录所有报错对象，然后针对性地处理。不要指望迁移工具一键完成，做一次模拟迁移的成本比在生产上踩雷低得多。

5. 备份恢复与高可用——关键时刻别掉链子

做DBA这行，平时80%的功夫都花在“保证数据不丢、服务不中断”上。金仓的备份恢复体系同样沿袭了PG的思路，但具体命令名不同，很多从Oracle转过来的人会在这一步卡一下。这一章把逻辑备份、物理备份和高可用方案都过一遍。

5.1 逻辑备份 sys_dump

逻辑备份的命令是sys_dump，对应PG里的pg_dump。它导出的是SQL文本或自定义格式的归档文件，适合做表级、schema级的定向备份，也是数据迁移中最常用的手段。

典型的备份命令：

# 导出整个数据库为SQL文件 sys_dump -U system -d test -p 54321 -f /backup/test.sql # 导出为自定义格式（支持并行恢复和选择性恢复） sys_dump -U system -d test -p 54321 -Fc -f /backup/test.dump # 只导出某个schema sys_dump -U system -d test -p 54321 -n myschema -f /backup/myschema.sql # 只导出某个表 sys_dump -U system -d test -p 54321 -t public.user_info -f /backup/user_info.sql

恢复用sys_restore或者直接在ksql里执行SQL文件：

# 恢复自定义格式备份 sys_restore -U system -d test -p 54321 /backup/test.dump # 恢复纯SQL脚本备份 ksql -U system -d test -p 54321 -f /backup/test.sql

这里有一个我多次踩过的坑：备份时没带schema名，恢复到另一个库里时，对象可能跑到了错误的schema下，导致业务连不上。所以在备份策略里建议用-n显式指定schema，恢复前先用\dn确认目标库的schema情况。

逻辑备份不适合超大数据量的全库备份，一是耗时长，二是恢复时对事务和锁的处理比较多。它的定位是“逻辑导出、异构迁移、单表恢复”，不能替代物理备份。

5.2 物理备份 sys_basebackup

物理备份对应PG里的pg_basebackup，它直接复制整个数据目录，包含所有数据文件、WAL日志、配置文件，做的是物理级的一致性快照。恢复的时候不需要重新执行SQL，直接起一个新的数据目录就能用，所以更适合大规模全库恢复。

典型命令：

sys_basebackup -U system -D /backup/full_backup -p 54321 -Ft -z -P

参数说明：-Ft表示输出为tar格式包，-z表示压缩，-P显示进度。

物理备份恢复的流程稍微复杂一点：

1. 准备一个新实例的数据目录，用相同的版本初始化，可以把原配置文件复制过来。
2. 把备份解压到目标数据目录，注意目录属主要改成kingbase用户。
3. 如果备份时数据库还在运行，恢复时需要配合WAL日志做前滚，保证数据一致性。
4. 启动新实例，验证数据。

生产上做全量备份的时候，我最常用的组合是：每周一次sys_basebackup全量，每天一次WAL归档增量，这样能把恢复时间窗口控制在几分钟内。这个思路本质上就是PG的“全量+归档”体系，也是绝大多数数据库备份方案的通用逻辑。

5.3 高可用方案简述

金仓的高可用，目前实际项目里最常见的是基于流复制的架构。它跟PG的流复制原理一样：主库把WAL日志实时发送到备库，备库持续回放WAL，保持与主库的数据同步。再搭配一个VIP或者中间件做故障切换，就能实现分钟级的自动故障恢复。

我参与过的生产部署里，比较稳妥的架构是“一主一备 + 仲裁”，备库开启只读模式，平时还能分担一部分查询流量。切换工具方面，官方有配套的高可用组件，社区里也有人直接用Patroni类方案来管理。金仓的流复制配置和PG大同小异：

1. 主库开启wal_level = replica、archive_mode = on，创建具有复制权限的用户。
2. 用sys_basebackup把主库复制到备库节点。
3. 在备库配置recovery.conf或对应的standby设置，填主库连接信息和复制用户。
4. 启动备库，查看流复制状态确认主备同步正常。

注意：高可用架构不能只在部署的时候看是否同步，一定要在业务低峰期做故障切换演练。真到数据库挂了才第一次切换，大概率手忙脚乱，而且恢复时间不可控。

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

最后这一章，我把自己在使用金仓过程中遇到频率最高的问题汇总成了一份速查手册，并给出了排查思路。这里面很多坑都不在官方文档的显眼位置，属于只有踩过才会关注到的经验。

6.1 从Oracle迁移过来的典型问题

问题1：存储过程里的FROM DUAL报错

在Oracle里SELECT ... FROM DUAL是常规操作，但金仓的Oracle兼容模式下虽然支持DUAL，有些版本的驱动或者连接参数没开兼容，还是会报错。排查时先确认SHOW compatible_mode;是不是oracle，再检查客户端连接串里有没有设置正确的兼容模式。如果都没问题，把SQL改成不带FROM子句的写法也能绕过。

问题2：迁移后表数据量对不上

原因是类型映射处理不当，最常见的是NUMBER(10)映射成了某个精度的数值类型，导致小数位被截断或者精度溢出。另外日期类型如果映射成timestamp，原始数据里只有日期没有时间部分，导入后就会多出一串00:00:00。解决办法是迁移前先在源库跑一遍数据特征分析，把所有小数位、日期范围、空值率摸清楚，再设计表结构。

问题3：字符串比较大小写不敏感

Oracle默认比较是大小写不敏感的（取决于排序规则），金仓里如果不设置相关参数，对字符串的比较是敏感的。用户迁移后反馈“原来能查出来的数据现在查不出来了”，定位之后发现是大小写问题。处理方法是统一在SQL里改小写，或者在建表时指定合适的排序规则。

6.2 启动失败与连接异常

问题：Docker容器启动后立刻退出

这个我遇到太多次了，80%的原因是数据目录权限问题。容器里kingbase用户对数据目录必须要有完整权限，如果你宿主机挂载的目录属主不对，初始化的时候就报权限错误。解决方法是先确保宿主机目录属主是kingbase的UID，或者用docker run --user指定用户运行，再或者先以root启动容器，进去手动chown数据目录，重启容器。

问题：ksql连接报“no pg_hba.conf entry”

这是金仓沿袭了PG的pg_hba.conf认证机制，你的客户端IP不在允许列表里。处理方式是编辑数据目录下的pg_hba.conf，添加一行：

host all all 0.0.0.0/0 scram-sha-256

然后重载配置sys_ctl reload。注意安全，生产环境下不要用0.0.0.0/0，要限制到具体的网段。

问题：Navicat/DBeaver连接报端口不通

先确认端口映射有没有做对，docker ps看映射关系。再用telnet 宿主机IP 54321测一把连通性。排查网络问题时，别一上来就怀疑数据库坏了，先走一遍：进程在不在→端口在不在→防火墙放没放→pg_hba放没放→用户名密码对不对。这个顺序能解决90%的连接问题。

6.3 性能问题排查思路

数据库变慢，是日常运维里最多的问题。我提供一个通用的排查思路，不分数据库类型，在金仓上也一样适用：

第一步，看系统资源。CPU、内存、磁盘IO、网络，先确认是不是资源耗尽导致的瓶颈。用top、iostat、vmstat这些常规工具扫一遍。

第二步，看数据库会话。执行前面那个pg_stat_activity查询，重点找状态是active但已经跑了很久的SQL，以及大量idle in transaction的会话。后者是被业务代码里忘记提交的事务卡住的，会一直持有锁，拖垮整个系统。

第三步，看锁等待。金仓里查锁等待，可以先查pg_locks，结合pg_stat_activity里的wait_event_type定位锁等待链。如果是行锁冲突，找到持有锁的那个会话，跟业务方确认是否可以杀掉：

SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE pid = 需要杀掉的进程id;

第四步，看慢SQL。金仓和PG一样默认没开慢查询日志，需要手工开启：

log_min_duration_statement = 1000 -- 单位是毫秒，超过1秒的SQL记录到日志 log_duration = on

开启后，把慢SQL抓出来用EXPLAIN ANALYZE分析执行计划，看有没有全表扫描、糟糕的关联顺序、或者类型转换导致索引失效。

第五步，看统计信息。数据量变化大之后，优化器用的统计信息可能已经过期，执行计划会跑偏。这时候直接ANALYZE;或者对关键表做ANALYZE 表名;，往往能立竿见影。我对那种“昨天还快、今天突然慢”的场景，第一反应就是这个。

抓执行计划的一个典型操作：

EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM user_info WHERE name = '张三';

看输出里有没有Seq Scan全表扫描，有没有预估行数和实际行数差距巨大。如果差距大，先analyze再重新抓计划。

提示：杀会话之前一定跟业务方确认，那个会话是不是正在跑关键任务。pg_terminate_backend不会做事务回滚保护，所有未提交修改会直接丢。我见过DBA手滑杀掉会话，导致业务侧数据不一致的现场，教训惨痛。

结尾：一点个人体会

最后分享一点我自己的经验。学人大金仓，最大的捷径就是利用好你已有的PostgreSQL知识，不要因为它叫“金仓”就当成一个完全陌生的东西。先理解PG的体系结构和常用命令，再去对照金仓的差异点，学习曲线会平缓得多。遇到Oracle迁移的项目，宁可多花时间在迁移前的数据特征分析和存储过程改写方案上，也别指望迁移工具一键兜底，前期准备越充分，上线后的幺蛾子越少。

Docker方式适合快速起环境做验证，但如果是正儿八经的准生产或者生产环境，还是建议用物理机或者虚拟机按官方推荐方式部署，存储用本地盘或专业存储，别用容器网络搞复杂架构。备份这块，不管环境大小，全量加归档的策略必须提前定下来，不要等出了事故才想怎么恢复。

这套知识体系如果你能完整跑一遍，从部署到使用到运维再到排障，基本可以覆盖日常工作中99%的场景了。后续有机会我再单独写写金仓的优化器行为差异，那个话题展开讲又是一大篇。