简介：面向需要通过 Navicat 连接人大金仓数据库的数据库管理员、开发人员及运维人员，该文档以清晰的图文步骤，完整演示了从 Navicat 下载安装、创建连接、配置账号密码，到连接成功后创建数据库、转储 SQL 文件、复制为插入语句以及执行 SQL 的整套操作流程。内容特别指出字符集与排序规则需要和源库保持一致，建议使用 C 字符集，并对官方图形工具与 Navicat 的适用场景给出客观对比，能帮助读者规避乱码和连接失败等常见问题。压缩包内包含 1 个 docx 文档，大小约 1.62MB，按实际操作顺序组织章节，界面截图与说明文字一一对应，适合按步骤跟随操作。目前该资源已有 1293 人学习，经过较多使用者验证，可作为日常管理人大金仓数据库时的实用参考。

1. 用 Navicat 连人大金仓：下载、连接、迁移一条龙

很多项目切到国产数据库之后，第一件事就是把开发工具连上去。用 Navicat 连人大金仓时，最容易在第一层就卡住：新建连接的下拉列表里根本找不到“人大金仓”这个选项，选 PostgreSQL 又报端口拒绝，几番折腾下来连库都建不了，后续迁移更是无从谈起。这套流程我排过不少次，问题基本集中在版本选择、默认端口和排序规则三个点上。下面按“下载安装 → 创建连接 → 建库与迁移 → 避坑验证”的顺序，把每一步参数和取舍讲清楚，适合正在做国产化适配、或者手头刚拿到一套金仓环境的开发者，照着走完就能把库建起来、把数据导进去。

2. Navicat 下载与安装：版本选错，后面全白费

2.1 官网下载：Premium 版才支持多库连接

Navicat 的产品线很多，有 Navicat for MySQL、for PostgreSQL、for SQL Server 这类单库版本，也有 Navicat Premium 这种多库合一的版本。连接人大金仓，我建议直接用 Navicat Premium。原因很简单：金仓虽然走的是 PostgreSQL 协议，但你在 Navicat 里用的是“选 PostgreSQL 类型建连接”的方式，单库版也能连，可是当你要从 MySQL 或 Oracle 把数据迁过来时，单库版就帮不上忙了。Premium 一个工具里可以同时建好几个不同类型的连接，迁移时这边查 MySQL、那边写金仓，来回切换不用开两个软件。

下载地址是 Navicat 官网的下载页面，Windows 64 位系统认准 navicat161_premium_cs_x64.exe 这个安装包。文件名拆开看：161 是主版本号，cs 是简体中文语言包，x64 是 64 位架构。官网下载页会根据你的操作系统推荐文件，Windows 10/11 的 64 位系统直接下这个不会错；32 位系统需要找 x86 版本，现在虽然少见，但如果你在老旧服务器上装，还是要先看一眼系统类型再下载，别下完了才发现装不上。

版本兼容性这里多说一句。Navicat 主版本跨度大的时候，连接协议的行为会有差异。比如老版本客户端连接 PostgreSQL 兼容库时，对认证插件支持不全，会遇到“认证方式不支持”之类的报错。我一般直接装官网最新的稳定版，别拿几年前的旧安装包对付。人大金仓 V8 的认证机制和较新的客户端配合更好，旧版 Navicat 连上去容易出莫名其妙的问题，排查起来还特别费劲，不如一开始就装新版省心。

2.2 安装过程：装坏重装比想象中麻烦，提前避开两个坑

安装文件双击之后进入安装向导，前几步就是选择安装位置和组件。我一般会把安装路径从 C 盘改到 D 盘，比如 D:\Navicat Premium，避免 C 盘空间不足把系统盘塞满。组件选择那一步默认全选即可，不需要手动增减。这个软件整体不大，装完后占用空间在几百 MB 级别，主要看后续缓存和连接配置。

安装过程中真正要注意的有两个地方。第一个是安装到一半提示“无法写入注册表”，或者被杀毒软件拦截。Navicat 安装时会在注册表写入文件关联和卸载信息，某些安全软件会把安装程序当恶意行为拦下来。遇到这种情况，先暂时关闭安全软件的文件监控，装完再打开，不要直接点“忽略”继续。一旦关键组件没写全，装出来的程序启动时会报缺文件，到时候还要重装，更麻烦。

第二个是重装问题。Navicat 卸载之后，注册表里会残留 PremiumSoft 相关的键，直接装新版有时会沿用旧版配置，导致界面语言、激活状态异常。我处理过一台机器，旧版卸载后装新版，启动就闪退，最后把注册表里残留项清掉才恢复正常。如果你遇到装完打不开的情况，备份好连接配置后，清理注册表残留再装一次是有效的后悔药。

提示：清理注册表之前先导出备份，删错键可能导致其他软件异常。另外激活信息也存放在这类键里，清掉之后需要重新激活，操作前想清楚。

安装完成后，桌面上会出现 Navicat Premium 的快捷方式，首次启动会弹出激活或试用窗口。试用期 14 天，功能完整，连接、建库、转储、执行 SQL 都不受限，临时用完全够。长期使用需要激活，这个按你自己的正规渠道处理，本文不展开。第一次打开软件后会看到一个空白主窗口，左侧是连接列表，顶部是菜单栏。这时候先别急着点新建连接，先确认目标金仓数据库服务是启动状态。

金仓装好后会在系统里注册一个服务，Windows 上到服务管理里看状态是否为“正在运行”。服务都没起来，Navicat 这边怎么填参数都是白搭。这一步很多人忽略，结果在 Navicat 里反复试错，最后发现是服务没启，白白浪费半小时。先确认服务，再打开客户端，这个顺序别搞反。

3. 创建连接与账号配置：参数逐项拆解

3.1 新建连接：类型选 PostgreSQL，端口改成 54321

在金仓服务确认启动后，回到 Navicat，左上角点“连接”，弹出数据库类型选择列表。这里没有“人大金仓”或“KingbaseES”选项，正确操作是选 PostgreSQL。这话我说得直白一点：Navicat 不认识金仓，但金仓认识 PostgreSQL 协议，选 PostgreSQL 类型连接是官方之外最常见也最稳的接法。

选完类型后，弹出连接参数窗口，需要填的信息有连接名、主机、端口、初始数据库、用户名、密码。关键参数我列个表对照：

最容易踩的是端口。Navicat 选了 PostgreSQL 之后，端口默认停在 5432，这是原版 PostgreSQL 的默认端口。人大金仓的默认端口是 54321，如果你不改，点测试连接必然报“连接被拒绝”。我第一次连金仓就在这里卡了十来分钟，后来发现是端口没改，改成 54321 一次就过了。如果你不确定金仓端口有没有被改过，去金仓安装目录下的 data 配置文件里看 port 参数，或者直接问搭环境的人。

连接名这个字段容易让人误会，它不是数据库名，只是你在 Navicat 里给这个连接起的别名。同一个金仓实例，你可以建两个连接，一个叫“生产库”一个叫“测试库”，指向不同 IP 或不同端口、不同用户，方便区分。连接名怎么起都行，但建议带环境标识，省得连接一多自己都分不清哪个是哪个。

3.2 账号密码与连接测试：失败时先查这三个地方

参数填完之后，点右下角的“测试连接”，Navicat 会尝试连一次并给出结果。如果弹出“连接成功”，说明参数没问题，点确定保存连接即可。如果报错，按下面的优先级排查，别瞎改参数，越改越乱。

第一，端口和地址。报“连接被拒绝”或“无法连接到服务器”，先确认金仓服务正在运行，再确认端口写的是 54321 而不是 5432。本机连接可以试 localhost，远程连接要确认网络通不通，telnet 一下端口看是否通。防火墙拦截也是常见原因，Windows 防火墙要在入站规则里放行金仓端口，Linux 服务器上则是 firewalld 或 iptables 的规则问题。

第二，账号密码。报“密码认证失败”或“用户名不存在”，基本就是用户名或密码错了。金仓安装时设置的超级用户是什么就用什么，不要自己想当然填 postgres 或 root。有些环境里管理员给的是业务普通账号，密码带特殊字符，注意别在复制时把前后的空格也带进去，这种错误很隐蔽，肉眼看不出来。

第三，认证方式。如果报“不支持认证方式”之类的错误，问题出在 Navicat 版本太久，或者金仓服务端配置的认证插件和客户端对不上。常见做法是先升级 Navicat 到最新版，再看金仓服务端能不能把认证方式调整为兼容模式。这个坑在国产库上不算少见，因为服务端默认配置往往偏向安全强度，老客户端解析不了新的认证握手。

连接成功之后，左侧连接树下会展开这个实例下的数据库列表。金仓安装后默认会有几个内置库，比如 TEST、SECURITY 之类的系统库。先展开 TEST 库，看看里面的表能不能正常列出，能列出说明 SELECT 权限正常。别一上来就建生产库，先用默认库把连接验证透。连接保存后想改参数，右键连接名选“编辑连接”就能改，不需要删了重建；如果有多套环境要连，右键连接名选“复制连接”，改个 IP 和连接名就又是一套，比从零建省事。

4. 建库、排序规则与数据迁移：乱码的源头在这里

4.1 创建数据库：排序规则选 C，别让乱码从建库就埋下

连接验证通过之后，就可以创建业务数据库了。在左侧连接树的实例节点上右键，选“新建数据库”，弹出创建对话框。这里要填数据库名、字符集、排序规则三项，最容易出问题的是排序规则，其次是字符集。

金仓自带的图形管理工具创建数据库时，默认用的是 zh.CN.UTF-8 排序规则。这个规则在中文环境下看起来合理，但在数据迁移场景下是个隐患。Navicat 创建数据库时，排序规则默认可能跟着服务端模板走，你需要手动把它改成 C。规则很简单：源库用什么排序规则，目标库就用什么；如果拿不准，直接用 C。C 排序规则按字节比较，行为最稳定，跨库迁移时不容易出现大小写和中文排序差异。

反过来，用 zh 开头的中文排序规则在部分兼容库版本上表现不稳定，同样的 SQL 在源库和目的库跑出来顺序不一样，排查起来非常耗时间。原文里专门提到“建议使用 C，使用自带图形工具创建的为 zh.CN.UTF-8 类型，建议使用 navicat”，这句话的实操含义就是：建库时别用金仓自带工具的默认值，用 Navicat 手动把排序规则改成 C，字符集选 UTF8。

注意：排序规则在建库时确定，之后修改很麻烦。建库前先看源库用的什么规则，保持一致，不要在这里偷懒。已有数据再改排序规则，基本等于重建库。

建库之后，可以用一条 SQL 验证库的字符集和排序规则：

-- 查询当前实例下所有数据库的字符集和排序规则 SELECT datname, pg_encoding_to_char(encoding) AS encoding, datcollate, datctype FROM pg_database WHERE datname = '你的库名';

这条语句在人大金仓上可以正常执行，因为它兼容 PostgreSQL 的系统表结构。datcollate 显示排序规则，datctype 显示字符分类，如果你建库时选的是 C，这里会显示 C 或 C.UTF-8 之类的值。看到这个值，说明建库参数真正生效了，不是界面选了就完事。这一步很多人跳过，结果乱码了再回来查，才发现建库时参数就没设对。

4.2 转储 SQL 文件与执行脚本：迁移的标准顺序

建好库之后，接下来是把数据迁进来。Navicat 里最常用的两个功能是“转储 SQL 文件”和“运行 SQL 文件”，搭配使用就能完成一次完整的库级迁移。我通常的操作顺序是：在源库上转储 SQL 文件，再连接到目标库所在的实例，右键目标数据库选“运行 SQL 文件”，把转储出来的脚本执行一遍。

转储 SQL 文件这个操作，在 Navicat 里是右键数据库名，选“转储 SQL 文件”，然后选“仅结构”或“结构和数据”。迁移场景选“结构和数据”，备份场景可以只选数据。转储出来的文件是纯文本，里面是 CREATE TABLE、INSERT INTO 这类语句，可以用任意文本编辑器打开检查。转储前留意一下文件大小，如果表特别大，转储时间会比较长，耐心等，别中途关窗口。

这里有个参数取舍要说一下。转储时 Navicat 会问要不要包含“创建数据库”语句。如果你已经把目标库建好了，就不要勾选创建数据库，否则执行时会在脚本开头遇到 CREATE DATABASE 冲突，整个脚本直接中断。我一般只在目标库完全空白、需要连库一起建的时候才勾选这个选项。

复制为插入语句是另一个实用功能。在表的数据页里选中若干行，右键选“复制为插入语句”，Navicat 会把选中的行生成 INSERT 语句复制到剪贴板。这个功能适合只迁移几张表、或者往表里补几条数据的情况，不用整个库转储那么重。生成的语句可以直接粘贴到查询编辑器里执行，但要注意字段名如果是关键字或者带大小写，生成语句时会自动加双引号，别手动把引号删掉，删了反而容易触发标识符解析问题。

执行 SQL 文件时，小文件可以直接打开查询编辑器，把整个 SQL 文件内容粘贴进去点运行；大文件建议用“运行 SQL 文件”功能而不是复制粘贴，因为编辑器粘贴几十万行内容容易卡死。运行 SQL 文件功能在右键菜单里，选择文件后 Navicat 逐段执行，执行完会报告每条语句的成功或失败状态。如果中途报错，不要急着改文件重跑，先看报错停在哪个对象上。INSERT 语句已经插入了一部分，直接重跑会导致主键冲突，得先清掉已插入的数据。

从 MySQL 迁过来的场景要额外注意类型差异。MySQL 的 datetime、tinyint、enum 这些类型，在金仓里对应关系不完全一致。转储 SQL 文件之前，先看源库有没有特殊类型。Navicat 在转储时对 MySQL 的引擎和字符集标注和金仓的语法不兼容，直接跑 MySQL 转出来的脚本大概率报错。常见做法是先在金仓里建好表结构，再用复制为插入语句的方式导数据，绕开 CREATE TABLE 语法差异。这一步虽然原始，但胜在可控，不会半夜迁数据迁到一半被类型报错叫醒。

5. Navicat 连人大金仓避坑指南：高频翻车现场逐个拆

5.1 端口拒连：默认 5432 连不上金仓

现象：Navicat 选 PostgreSQL 类型建连接，测试连接报“连接被拒绝”。

原因：Navicat 的 PostgreSQL 连接模板默认端口是 5432，而人大金仓的默认端口是 54321，除非搭环境的人改过配置。

解决：编辑连接，把端口改成 54321 再测试。如果改了还不行，去金仓安装目录的 data 配置文件里确认实际端口，或者问管理员。另外检查服务是否启动，Windows 服务管理里看金仓服务状态，服务没起，端口自然不通。

5.2 导入数据乱码：排序规则和字符集不一致

现象：转储 SQL 文件在目标库执行后，查询表数据，中文变成问号或乱码。

原因：源库和目标库的字符集或排序规则不一致。建库时用了 zh.CN.UTF-8 或服务端默认值，而源库用的是 C，导致数据写入时编码行为不同。

解决：建库时把排序规则设为 C，字符集设为 UTF8，和源库保持一致。已有乱码数据的库，把数据导出成 CSV 或 SQL，重建库后再导入。别指望用 ALTER DATABASE 改排序规则，兼容库上这个操作限制很多，重建库是最稳妥的后悔药。

5.3 登录失败：账号带特殊字符或权限不足

现象：密码明明正确，测试连接却报认证失败；或者连接成功但看不到业务库的表。

原因：密码里有特殊字符，复制粘贴时带了不可见空格；或者当前账号只有登录权限，没有库级 SELECT 权限。

解决：密码手输一遍试试，排除复制带空格的可能。权限问题用超级用户登录，给业务账号授权后再用业务账号连接。授权时注意库名和模式名要写对，国产库环境里这些细节经常被忽略。

5.4 转储文件执行报错：对象顺序和主键冲突

现象：运行大型 SQL 文件，执行到中途报错，错误信息指向某张表已存在或主键重复。

原因：转储文件里包含了 CREATE TABLE 语句，而目标库已经有同名表；或者之前执行失败后没有清理，再次执行时 INSERT 主键冲突。

解决：目标库的表先清空，或者新建一个干净的库再执行。如果执行到一半失败，先清理已插入的数据再重跑。另一个做法是转储时只选“数据”，不选“结构”，这样不建表只插数据，避免结构冲突。

5.5 连接类型选错：Oracle 模式和 PostgreSQL 模式的差别

现象：用 Navicat 的 Oracle 类型连接金仓，连接成功但查询系统表报错，功能异常。

原因：人大金仓有两种兼容模式，一种兼容 PostgreSQL，一种兼容 Oracle。Navicat 没有金仓专用类型，如果按 Oracle 模式建连接，语法解析走的是 Oracle 路线，和 Navicat 内置的 Oracle 客户端行为不一致。

解决：查看金仓初始化时选的兼容模式。如果是 PG 模式，Navicat 里用 PostgreSQL 类型连接；如果是 Oracle 模式，仍然建议用 PostgreSQL 类型连接，把 SQL 写成 PG 风格。Navicat 对 PG 协议的支持比对 Oracle 协议的兼容更稳，这是我在实际环境里对比过的结论。

5.6 表名大小写：建的表查不到

现象：在金仓里执行 CREATE TABLE UserInfo 成功，但在 Navicat 左侧树里看不到这张表，执行 select * from UserInfo 报表不存在。

原因：兼容库对未加引号的标识符做小写化处理，CREATE TABLE UserInfo 实际建的表名是 userinfo，而 Navicat 树里展示的可能是带原始大小写的名字，导致看起来“消失”了，其实是大小写不一致。

解决：统一使用小写表名，或者建表时给表名加双引号强制保留大小写。查询时也要和建表时保持一致，否则会被判定为不同的表。这个坑在从 Oracle 迁过来的场景里特别常见，因为 Oracle 默认大写存储，习惯一时改不过来。

6. 装完怎么验证：从连接测试到 SQL 执行跑通

Navicat 连金仓到底算不算装通了，我的判断标准不是“连接测试弹了成功”，而是完整走一遍：建库 → 建表 → 写数据 → 转储 → 在另一个空库执行。这套流程走完，说明从客户端到服务端的链路、权限、字符集全部正常，后面正式迁数据才敢动手。

第一步，连接测试。新建连接，类型选 PostgreSQL，端口 54321，填好账号密码，点测试连接，弹出成功提示。

第二步，验证服务端身份。新建查询，执行下面这条语句：

SELECT version();

返回的字符串里应包含 Kingbase 相关字样。这一步能确认你连的确实是金仓，而不是某个误填端口后连到的别的 PostgreSQL 实例。多环境混跑的机器上，这个验证尤其重要。

第三步，建库验证。新建数据库，字符集选 UTF8，排序规则选 C。建完执行查询：

SELECT datname, pg_encoding_to_char(encoding) AS encoding, datcollate FROM pg_database WHERE datname = 'testdb';

看到编码为 UTF8、排序规则为 C，说明建库参数生效。

第四步，建表写数据。在库里建一张简单的表，插入一条中文数据，再查询出来，确认中文不乱码：

CREATE TABLE t_verify (id int, name varchar(50)); INSERT INTO t_verify VALUES (1, '中文测试'); SELECT * FROM t_verify;

查询结果里中文显示正常，字符集链路就通了。

第五步，转储回环。右键数据库转储 SQL 文件，再新建一个空库，运行刚才转储的文件，确认数据完整。这一步能验证转储和执行两个方向都正常，也能顺带检验排序规则在真实数据上的表现。

从那以后，我每次拿到一套新的金仓环境，都强制自己把这五步完整走一遍，大约十分钟。别小看这十分钟，它能在一开始就把端口、权限、字符集的问题全暴露出来，省得后面迁数据迁到一半才发现连不上，进退两难。希望这套验证流程帮到你，少走我当年走过的弯路。

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