简介：面向需要连接与管理人大金仓数据库的开发、运维及数据迁移人员，这份docx文档以Navicat为工具，梳理从软件认知到日常操作的完整路径。内容依次覆盖Navicat简介与官网下载安装、创建连接、账号密码配置、连接成功后的对象浏览，以及新建数据库、转储SQL文件、复制为插入语句、执行SQL语句等常用场景，并对排序规则与字符集一致性、官方图形工具取舍、账号权限与密码安全等注意事项作出提示，便于读者少走弯路。压缩包内仅含1个docx文件，大小约1.62MB，目录层级清楚，适合按章节查阅或作为操作备忘录。已有1302人学习，说明该主题在国产数据库适配中具有一定关注度。读者可据此快速搭建Navicat连接环境，掌握库表管理、SQL导出与数据迁移的常用方法，并理解字符集配置等易错点，提升人大金仓日常维护效率。

1. 用 Navicat 连接人大金仓的第一次翻车

那台服务器上的库是人大金仓，我图顺手，在 Navicat 里新建了一个 PostgreSQL 连接，主机、库名、账号都按运维给的文档填好，点「测试连接」，转圈十几秒，弹出来一句连接超时。我以为网络不通，ping 通了；以为账号错了，命令行能登。折腾到后半夜才发现，端口那一栏我留了默认的 5432，而那套实例监听的是 54321。

后来这类问题又遇到过几次：连上了但对象树空空如也，建完库中文全变成问号，转储出来的 SQL 导不回去。Navicat 连接人大金仓这件事，协议是通的、界面是友好的，坑全在几个默认值和字符集选项上。这篇就按我实际部署的顺序，把版本、参数、建库、转储和排错一次写清，适合第一次把业务库接进 Navicat 的开发者照着走。

2. 环境清单与版本对照：Navicat 16.1 配人大金仓要对的四个参数

动手之前先把清单列出来，比装到一半再回头查要省事得多。这一层看起来像准备工作，其实是整篇里最容易埋雷的地方——端口、库名、模式、编码，四个参数错一个，后面的操作都白做。

2.1 Navicat 版本怎么选：Premium 16.1 与单库版的差别

我手上这套是navicat161_premium_cs_x64.exe，也就是 Navicat Premium 16.1 中文 64 位版。选 Premium 而不是单库版的原因很实际：迁移现场往往不止一个库，源端可能是 MySQL 或者 SQL Server，目标端是人大金仓，Premium 可以在同一个窗口里开多个连接互相拖数据，不用在两个程序之间来回切。

几个版本上的取舍，我按踩过的顺序说：

• 16.x 的主程序是 64 位，安装包里会额外问你要不要装 32 位附加组件。那个东西是给很老的插件或者 OLE 组件用的，只连人大金仓的话不用勾。
• 15 和 16 在连接属性页上差别不大，16 的「高级」页签里编码下拉更完整，保活间隔的默认值也更合理。如果团队里已经统一了 15，不用为了这一个功能升级。
• 网上流传的绿色版、精简版，我一般不建议用在生产连线上。它们经常缺 PostgreSQL 驱动文件，表现就是连接类型选对了却一直报驱动加载失败，出了问题很难复现，也没有安装日志可查。
• Navicat 与人大金仓之间没有官方发布的兼容性矩阵，实际做法就是看协议：人大金仓兼容 PostgreSQL 的连接协议，Navicat 用 PostgreSQL 驱动连过去基本都能通，剩下的差异在系统视图和方言上。所以版本选择的重点不是「支不支持」，而是「驱动新不新」。

2.2 连接前必须确认的四个参数

这四个值建议先在纸上写死，再去 Navicat 里填。现场临时问人，十有八九会漏掉模式那一条。

端口这一条值得单说。PostgreSQL 的默认端口是 5432，Navicat 新建 PostgreSQL 连接时也会把 5432 预填进去，而人大金仓出厂默认监听 54321。两边默认值不一样，填的时候又不显眼，于是就成了我见过最多的「连不上」原因。拿到实例后先确认kingbase.conf里port的实际值，或者直接问 DBA 要一句准话，别信记忆。

2.3 客户端环境：连通性、防火墙与编码

Navicat 装在本机，库在服务器上，中间隔着防火墙和安全组。装之前先做一次连通性测试，把「网络问题」和「Navicat 配置问题」分开，后面排错能省一半时间。

# Windows 上先确认端口通不通，排除 Navicat 背锅 Test-NetConnection -ComputerName 192.168.10.21 -Port 54321

TcpTestSucceeded : True才说明链路没问题。如果这里是 False，先在服务器上netstat -ano | findstr 54321看实例有没有真的在监听，再看防火墙有没有放行这个端口，最后才回头怀疑客户端。

编码这件事在 Windows 上尤其要注意。中文版 Windows 的系统区域设置默认代码页是 GBK，某些情况下 Navicat 会跟随系统编码去解析返回的数据，中文就变成问号。稳妥做法是在连接的「高级」页签里把编码显式设成UTF8，不要留「自动」。同一台机器上如果还装了人大金仓自带的命令行客户端，系统环境变量PGCLIENTENCODING也会影响它，那个变量对 Navicat 不生效，两边要分开配。

3. 安装 Navicat 16.1 并建立到人大金仓的连接

环境参数确认完，接下来是从 exe 到连接成功的整条路径。这一章的动作都不复杂，但每一步都有一个「选错也能继续往下走、直到最后才报错」的分支，我会把这些分支点标出来。

3.1 安装包获取与安装向导里的三个选项

安装包从 Navicat 官网的下载页拿，选 Windows 平台、64 位、中文版，文件名就是前面提到的navicat161_premium_cs_x64.exe。下载完直接双击，安装向导会依次问三件事：

第一是安装路径。默认在C:\Program Files\PremiumSoft\Navicat Premium 16，我一般不改，但有一点要提醒：路径里不要带中文，也不要有空格之外的奇怪符号。某些插件在加载时对路径处理不严谨，装在中文目录下会表现为启动后功能页签空白。

第二是是否创建桌面快捷方式，这个随意。

第三是是否安装 32 位附加组件。前面说过，只连人大金仓不需要，勾了反而多装一堆用不上的东西。

装完首次启动会弹出许可窗口，按手上的授权方式处理就行，试用期内功能是完整的，我通常先用试用期把连通性和字符集验证跑一遍，确认这套方案能落地，再走正式的授权流程。

提示：安装过程中如果杀毒软件弹窗拦截写入注册表，选择允许。被拦下的表现是装完了但连接类型列表里少了几项。

3.2 新建连接：类型选 PostgreSQL，别去「其他」里找

打开 Navicat，左上角「连接」按钮下拉，选PostgreSQL。Navicat 的连接类型列表里不一定有单独的人大金仓条目，业界通用的做法就是借 PostgreSQL 协议连——人大金仓兼容这套协议，驱动层面走得通。

弹出的连接窗口里填这几项：

• 连接名：自己认得出就行，建议写成金仓-业务库-生产这种带环境标识的格式，免得测试库生产库混在一起。
• 主机：实例 IP，不要带端口。
• 端口：54321，就是这一栏决定了你今晚几点下班。
• 初始数据库：填业务库名。留空的话 Navicat 会连到实例的默认库，进去看不到自己的表，很容易误判成「库没建成功」。
• 用户名 / 密码：出厂常见的是system，生产环境应该用单独建的、权限收敛过的账号。

填完先别急着点确定，点左下角的「测试连接」。这一步返回成功，才说明四个参数全对。

3.3 高级选项：编码、保活与 SSL

「测试连接」通过之后，切到「高级」页签再补三项设置，这三项决定了长时间挂着会不会掉线、中文会不会乱。

# Navicat 连接属性 - 高级页签，按这个思路填 编码 = UTF8 # 不要留“自动”，Windows 中文环境下容易跟随 GBK 保持连接间隔 = 120 # 单位秒，防止中间设备把空闲连接掐掉 使用压缩 = 关闭 # 内网带宽充足时没必要开，开了反而增加 CPU SSL = 关闭 # 内网直连一般不开；开启需要服务端配好证书

编码选UTF8是硬要求，尤其当源库和目标库都是 UTF8 的时候，客户端再用 GBK 去解，中文必然出问题。保活间隔设 120 秒够用了，太短会产生大量无用心跳，太长则跨过防火墙的空闲超时阈值，表现是挂一晚上第二天点啥都转圈。

SSL 这一项要看实例怎么配的。默认安装一般不启用 SSL，连接属性里保持关闭；如果服务端要求加密连接，这里打开的同时还得指定证书文件，配错了会直接连不上，报的是握手失败而不是认证失败，别被这个报错误导。

3.4 连上之后先做三件事：切模式、看对象树、开查询窗口

双击左侧的连接名，变绿就表示连上了。这时候别急着建表，按顺序做三件事确认环境是对的。

第一，展开「数据库」节点，找到你的业务库，再展开它下面的「模式」。人大金仓的对象是挂在模式下的，默认模式是public，但很多业务库会自建一个同名模式或者按业务划分的模式。如果只看到public而业务表不在里面，就在连接属性里把「模式」设成正确的那个，或者右键模式节点手动打开。

第二，新开一个查询窗口，跑一句最简单的确认：

-- 确认连到的是金仓实例，而不是同网段某台 PostgreSQL SELECT version();

返回的字符串里会带人大金仓的版本标识。这一步的意义在于排除「连错实例」——内网里同时有 PostgreSQL 和人大金仓的情况并不少见，两者端口不同但 IP 相邻，填错一位照样能连上。

第三，顺手看一眼当前库的编码：

-- 当前连接的库级编码，后面建库时要跟这个保持一致 SELECT datname, pg_encoding_to_char(encoding) AS encoding, datcollate, datctype FROM pg_database WHERE datname = current_database();

encoding应该是UTF8，datcollate和datctype记下来，建新库时要么跟它一样，要么明确知道自己为什么不一样。

4. 建库、字符集与数据进出：乱码和导入报错都出在这一步

连接通了只是开始，真正决定这套环境能不能长期用的是字符集和排序规则。这一章把建库、转储、执行脚本串起来写，因为它们的失败往往是同一个原因。

4.1 用 Navicat 新建数据库时那几个下拉框

在连接名或者已有库上右键，「新建数据库」，弹窗里除了库名，还有编码、排序规则（collation）、字符分类（ctype）三个下拉框，以及一个模板选择。

-- 等价于在查询窗口直接建库，参数看得更清楚 CREATE DATABASE appdb WITH ENCODING = 'UTF8' LC_COLLATE = 'C' LC_CTYPE = 'C' TEMPLATE = template0;

三个参数的含义：ENCODING决定字符怎么存，只要业务有中文就应该是UTF8；LC_COLLATE决定字符串怎么比大小和排序；LC_CTYPE决定大小写转换、字符分类这些行为。TEMPLATE = template0是关键——只有从干净模板建库，才允许自由指定编码和排序规则，用template1建会继承它的设置，改不动。

如果实例里没有template0这个选项，就在图形界面的模板下拉里选空，效果一样。建库账号需要有CREATEDB权限，权限不够时报的是「permission denied to create database」，跟参数无关。

4.2 C 与 zh_CN.UTF-8 的取舍

这是整篇里最需要想清楚的一处。原始资料里的建议是用C，同时提到人大金仓自带的图形工具建出来的库是zh_CN.UTF-8类型。两个都用过之后，我的结论是：不要在迁移过程中改排序规则，源库是什么就用什么；如果是全新建库，优先C。

zh_CN.UTF-8的问题不在于不好，而在于它依赖操作系统的 locale 支持。源库在 A 机器上是zh_CN.UTF-8，迁到 B 机器时如果 B 上没装中文 locale，建库那一步直接报错，报错信息还不太好懂。C没有这个依赖，代价是ORDER BY中文按字节排——如果你的业务里有中文姓名排序这种需求，就得在应用层或者查询里显式处理。

真正要避免的是混用：一个库C，另一个库zh_CN.UTF-8，然后两边互相导数据。这样导过去的字符串长度、索引命中、排序结果都可能对不上，而且不会立刻报错，属于典型的定时炸弹。

4.3 转储 SQL 文件：结构、数据、两者分开

Navicat 的转储入口在右键菜单里，选「转储 SQL 文件」，然后再选「结构和数据」「仅结构」或「仅数据」。这三种模式建议按场景分开用，别图省事一把梭。

• 仅结构：迁移到新环境时先跑这个，把表、索引、约束建起来，确认没有语法不兼容，再灌数据。人大金仓对 PostgreSQL 方言的兼容度很高，但序列、自增列、某些类型转换的写法仍有差异，先建结构能提前暴露问题。
• 仅数据：结构建好之后单独导数据，出错了可以只重跑数据这一半，不用把表删了重建。
• 结构和数据：小库图快可以这么干，大库不建议，中途失败整个文件都得重来。

转储对话框里还有几个要注意的点：文件编码选UTF-8；「包含 DROP TABLE」这个勾要慎重，勾了之后导入时会先删同名表，在目标库已有数据的情况下就是灾难；大库按模式分次转储，一个几百张表的库一次性导出，内存和文件体积都不好控。

4.4 复制为插入语句与执行 SQL 脚本

「复制为插入语句」是个小功能，但用在数据核对上很顺手。在结果集里选中几行，右键「复制为插入语句」，剪贴板里就是现成的INSERT语句，可以直接贴到另一个库的查询窗口里跑。

-- 从结果集“复制为插入语句”得到的内容大致长这样 INSERT INTO "public"."t_order" ("id", "order_no", "amount") VALUES (1, 'SO20240101', 99.50); INSERT INTO "public"."t_order" ("id", "order_no", "amount") VALUES (2, 'SO20240102', 128.00);

注意它只适合几十行以内的小数据。上千行的结果集生成出来，粘贴进编辑器能把 Navicat 卡住好一会儿，而且逐条INSERT效率极低，这种情况应该走转储。

执行 SQL 分两种入口。少量语句直接在查询窗口里写、点「运行」；大脚本走「运行 SQL 文件」，把.sql文件加载进去执行，别把几万行脚本粘贴到编辑器里再跑，编辑器会先撑不住。

-- 大批量导入时的稳妥写法：分批提交，别让一个事务扛全部 BEGIN; -- 这里放一批 INSERT，建议每 5000 行左右提交一次 COMMIT;

Navicat 的查询窗口有自动提交开关，默认是开的。跑大脚本时我一般关掉自动提交，手动控制BEGIN/COMMIT的边界，出错了能回滚，不至于留下半截数据。

5. 避坑与排查：五条踩过的记录

下面这五条都按「现象 → 原因 → 解决」写，基本覆盖了从连接到数据导入的完整链路。

5.1 测试连接一直转圈，最后超时

现象：主机、账号、密码全对，点「测试连接」转十几秒，弹出连接超时。

原因：九成是端口填错。Navicat 新建 PostgreSQL 连接时预填 5432，而人大金仓出厂默认监听 54321。剩下的一成是防火墙没放行或者实例只监听了 127.0.0.1。

解决：先用Test-NetConnection -ComputerName <IP> -Port 54321确认链路；链路不通就到服务器上netstat -ano | findstr 54321看监听地址，如果是127.0.0.1:54321，说明实例没对外监听，改配置文件里的listen_addresses；最后再检查防火墙和云上的安全组。

5.2 连上了，但对象树里一张表都没有

现象：连接状态是绿的，展开数据库和模式，表列表空的，但命令行查得到表。

原因：连的模式不对。人大金仓的对象挂在 schema 下，Navicat 默认打开public，业务表往往建在自建的模式里；另一种情况是初始数据库留空，连到了默认库。

解决：在连接属性的「模式」里填业务 schema，或者双击连接后手动展开所有模式节点。如果还是看不到，用SELECT current_database(), current_schema();确认当前落在哪，再对照 DBA 给的库名和模式名。

5.3 建完库，中文全部变成问号

现象：插入的中文在 Navicat 里显示正常，但通过应用读出来是???，或者反过来，应用写进去的中文在 Navicat 里是乱码。

原因：客户端编码和库编码不一致。Navicat 连接的编码留了「自动」，跟随 Windows 的 GBK 代码页；库本身是 UTF8，两边对不上。也可能是建库时LC_CTYPE跟源库不同。

解决：连接属性「高级」页签把编码显式设为UTF8；用 4.1 里那段 SQL 确认目标库的encoding、datcollate、datctype跟源库一致；不一致的库重新建，别在原库上改，改不动。

5.4 转储出来的 SQL 导不回去

现象：转储文件在目标库执行，报relation already exists，或者执行到一半报序列不存在。

原因：转储时勾了「包含 DROP TABLE」但目标库没有对应表，或者反过来，没勾但目标库已有同名对象。序列报错则是结构转储和数据转储的顺序搞反了。

解决：先「仅结构」导入并确认无报错，再「仅数据」导入；如果目标库是干净的，转储时不要勾包含 DROP；序列相关报错检查一下转储文件里CREATE SEQUENCE是否排在INSERT之前。

5.5 大脚本执行到一半卡死

现象：几万行的 SQL 文件粘贴进查询窗口点运行，Navicat 无响应，强退后数据只进了一半。

原因：编辑器在渲染超长文本时先耗尽资源，跟数据库没关系；另外自动提交开着，中途失败会留下半截数据。

解决：改用「运行 SQL 文件」入口加载.sql文件执行；关闭自动提交，手动分批BEGIN/COMMIT；执行前先SELECT count(*)记下目标表行数，跑完对照，确认没漏也没重。

6. 装完怎么验证跑通：三层验证，一层都不能省

装完能连上不算跑通，我一般按三层来验，每层都有明确的通过标准，缺一层后面都可能返工。

第一层验连接。用Test-NetConnection确认端口可达，用 Navicat「测试连接」确认认证通过，再在查询窗口跑SELECT version();确认连的是金仓实例。三层里这一层最快，出问题也最好定位。

第二层验字符集。在目标库建一张临时表，写一条中文进去再读回来：

-- 最直接的乱码探针：写进去什么样，读出来就该什么样 CREATE TABLE charset_probe (id int, note varchar(64)); INSERT INTO charset_probe VALUES (1, '中文落库验证'); SELECT * FROM charset_probe WHERE id = 1;

读回来还是「中文落库验证」，说明客户端编码、库编码、连接编码三处是一致的。这一步别省，乱码问题在空库上永远发现不了，等到业务数据灌进去再发现，清理成本完全不是一个量级。

第三层验数据链路。拿一张有代表性的业务表，走一遍「转储 → 在另一个库导入 → 比对行数」的完整流程：

三层全过，这套连接才算真正可用。我吃过一次亏：连接测试通过、中文探针也正常，结果转储文件在目标库导入时因为排序规则不同，唯一索引冲突，报了一堆重复键错误，业务侧等到第二天早上才发现。

从那以后我每次接新库，都强制把这三层验证走一遍，尤其是第二层的乱码探针和第三层的行数比对，哪怕 DBA 说「这库刚建的没问题」也照走不误。装环境这件事，后悔药从来都是提前吃的。希望帮到你。

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