简介：一份面向数据库管理初学者的图文操作指南，围绕使用Navicat连接国产人大金仓数据库的完整流程展开，系统讲解从工具下载安装、创建连接、配置账号密码，到新建数据库、转储SQL文件、复制插入语句及执行SQL语句等核心操作。文档同时针对字符集和排序规则给出明确建议，可帮助读者规避乱码问题，并理解连接配置中的关键细节。包体为单个docx文档，大小约1.62MB，内容结构清晰、步骤一目了然，适合需要快速上手Navicat与人大金仓协同工作的运维工程师、数据处理人员或数据库初学者。该资源已有1279人学习下载，除了完整的操作步骤说明，还包含使用官方工具与Navicat的对比提示、权限与安全注意事项等实用经验，便于读者在实际项目中灵活选用连接方式，提升国产数据库的管理效率。

1. Navicat 连人大金仓：为什么值得搭这一条连接

很多第一次接触人大金仓的同事，习惯直接用 KingbaseES 自带的图形工具，觉得"官方工具总不会错"。但我自己连着做了两个迁移项目之后，反而更推荐用 Navicat 去连金仓——不是因为官方工具不好，而是因为金仓兼容 PostgreSQL 协议，Navicat 对 PG 生态的连接、排查和 SQL 编写支持都足够成熟，界面也比自带工具更顺手。这条连接打通之后，日常建库、导数据、调试 SQL 都能在一套工具里完成，不用在几个客户端之间来回切换。这篇文章面向的是实施工程师、DBA 和数据迁移人员，把从下载安装、建连接、建库到转储 SQL 的完整链路过一遍，并把我踩过的排序规则、权限、端口这些坑一并说清楚。

2. 装好 Navicat 并建第一个连接：端口、驱动和账号是三个关键点

2.1 下载安装：官网拿安装包，注意版本位数

Navicat 的下载可以直接走官网，Windows 环境下选择 Navicat Premium 的 x64 安装包，例如navicat161_premium_cs_x64.exe。下载时注意两点：第一，操作系统是 32 位还是 64 位，现在金仓服务端基本都在 x64 环境，客户端也建议直接用 x64 版本，避免装出 32 位后在大表操作时内存受限；第二，Navicat Premium 是 All-in-One 的客户端，支持 MySQL、PostgreSQL、Oracle、SQL Server 等，连人大金仓时我们走的是 PostgreSQL 通道，所以不需要额外装"金仓专用版"。

安装过程没有特别要说的，一路下一步即可。需要注意安装路径不要放在带中文的目录下，Navicat 在某些中文路径场景下会出现莫名其妙的加载异常，虽然不常见，但没必要去赌这个概率。

2.2 连接前先确认三件事：端口、驱动、账号

在打开 Navicat 创建连接之前，我建议先确认三个信息，避免连不上时来回猜：

确认端口时可以直接在客户端机器上敲一下：

telnet 192.168.1.100 54321

如果端口不通，先看防火墙和安全组；如果通了，会出现连接成功的空窗口，说明网络层面没问题。我一般会在这一步多做一件事：用ping确认 IP 能通，再用telnet确认端口能通，两个都过了再开 Navicat，排错范围会小很多。

2.3 创建连接：选对连接类型，填入连接信息

打开 Navicat，点击左上角「连接」，下拉列表里没有写"人大金仓"的选项，但我们不需要选"MongoDB"或"MySQL"，而是选PostgreSQL。理由是人大金仓 KingbaseES 的对外协议兼容 PostgreSQL，Navicat 的 PostgreSQL 驱动可以完成握手。连接窗口里需要填这几项：

• 连接名：自己能识别的名字，比如金仓-UAT
• 主机：金仓服务器的 IP 或域名
• 端口：默认 54321
• 初始数据库：可以先填test或者template1，如果不知道有哪些库，就留空
• 用户名和密码：DBA 分配的账号

填完之后，可以先不点「确定」，点一下「测试连接」。如果弹窗提示连接成功，说明底层通了；如果弹的是认证失败，优先检查密码，其次查服务端的认证配置。这里有一个细节：Navicat 在连接 PostgreSQL 协议时，高级选项卡里有一项「编码」，建议直接选UTF-8。金仓的字符集默认就是 UTF-8，客户端编码不一致是后面乱码最常见的源头。

连接保存后，左侧列表会出现这个连接实例，展开之后能看到数据库列表、表、视图这些对象。到这里，Navicat 连金仓这条链路已经打通了。

3. 创建数据库：排序规则不一致，乱码会跟你到迁移完成

3.1 新建数据库时看到的三个下拉框分别管什么

连接建好之后，右键连接实例选择「新建数据库」，会看到名称、所有者、字符集、排序规则、字符分类这几个字段。很多人在这里直接点「确定」，等到迁移数据时才发现问题，那时候再改库的编码和排序规则就非常被动了。

Navicat 新建 PostgreSQL 类型数据库时，关键的三个选项是：

如果你看到的选项名是LC_COLLATE和LC_CTYPE，也不用慌，金仓兼容 PostgreSQL，这两个参数本质上就是排序规则和字符分类的底层实现。Navicat 的图形界面把翻译和原生参数混合在一起，有时候字段名会随版本变化，但逻辑是一致的。

3.2 C 和 zh.CN.UTF-8 到底差在哪

这是我在金仓迁移项目里被问得最多的问题，也是最容易翻车的位置。人大金仓自带的图形工具创建数据库时，默认的排序规则是zh.CN.UTF-8，字符分类同样是zh.CN.UTF-8。而 Navicat 这边默认值可能是C或者en_US.UTF-8，具体取决于客户端环境和所选模板。

排序规则为C时，数据库按字节序做字符串比较，规则简单、执行效率高，对索引的稳定性也更好；zh.CN.UTF-8是按中文本地化规则做拼音和笔画排序，更"智能"，但排序路径更长，而且一旦源库和目标库不太好，做关联查询时可能出现排序结果不一致或者索引走不上的情况。另一个实际问题是，中文本地化排序在部分金仓版本里对LIKE查询的支持不够稳定，遇到%关键词%这种带通配符的模糊匹配，执行计划会偏保守。

在金仓的场景下，我个人的习惯是新建库统一用C。原因很简单：业务系统里的排序需求通常最终落在应用层，数据库层用C排序不容易出现两边库排序结果对不上的情况。如果在迁移时发现两边的排序规则不一致，尽量改库，不要靠应用去适配。

3.3 排序规则不一致的典型故障

有人问：不就是 order by 的顺序不一样吗？真不止。排序规则不一致，先出现的往往是ORDER BY结果和源库对不上，紧接着是索引失效——因为 B-tree 索引的键顺序依赖排序规则，规则变了，优化器会认为已有索引不适用于当前排序要求，直接走全表扫描。再严重一些，涉及分区表、或者源表和目标表做 join 时，两边 collation 不同，数据库会直接报错：

ERROR: could not identify collation for join

这个错误在 Navicat 里会原样显示在消息窗口，看到它的第一反应就应该是去检查两张表的排序规则是否一致。我遇到过一次，排查了半天 join 条件，最后发现是两边的库一个用的zh.CN.UTF-8、一个用的C，把其中一边重建库后才恢复。

3.4 从金仓自带工具迁移过来的库，字符集陷阱怎么处理

如果你手上已经有一个用金仓自带工具建好的库，字符集是zh.CN.UTF-8，又不想重建，我的建议是分两步走。第一步，用 Navicat 连上这个库，先执行一段 SQL 确认当前实际参数：

select datname, pg_encoding_to_char(encoding) as encoding, datcollate, datctype from pg_database where datname = current_database();

这条 SQL 读的是 pg_database 系统表，在金仓的兼容层里同样能跑。encoding列显示实际字符集，datcollate和datctype显示排序规则和字符分类。拿到结果后，和源库比对一下这三个字段。如果源库和目标库的datcollate不一致，建议把目标库改成一致再导入数据。

第二步，在 Navicat 的「高级」选项卡里确认连接编码为 UTF-8，并在数据库属性里把默认字符集设为 UTF8。如果库已经建好，字符集和排序规则是没法直接改的，只能重建库或者用pg_dump导出后重新导入到新库。所以最省事的方法还是建库时就选对，后面不需要吃这个苦。

4. 转储 SQL、复制插入语句、执行查询：日常迁移操作三件套

4.1 转储 SQL 文件：导出前先分清 schema

连接打通、库也建好后，最常用的就是「转储 SQL 文件」。右键数据库，选「转储 SQL 文件」，Navicat 会弹出保存对话框，同时有几个勾选项：结构、数据、触发器、扩展等。默认全勾问题不大，但要注意一个坑：人大金仓默认的数据库是带publicschema 的，转储文件里会带CREATE SCHEMA public和 extension 创建语句，导入到新库时，如果目标库已经建过这些对象，会报"已存在"的错。

我的做法是：转储之前先确认目标库的状态。如果是空库就直接导入；如果目标库已经有对象，就在对话框里去掉「创建 schema」和「扩展」这两项，只保留表和数据的创建语句。另外，转储完成后用文本编辑器打开 SQL 文件看一下头部，确认第一段语句的类型，心里有数，导入时就不会对报错感到意外。

4.2 复制为插入语句：适合小表快速搬运

转储 SQL 适合全库级迁移，但有时候我只想挪一张表、或者把某几条数据搬到测试环境，这时候用「复制为插入语句」更快。操作路径是：在数据表上右键，打开表数据，选中若干行，右键选「复制为插入语句」，Navicat 会生成一串 INSERT 语句，直接粘贴到目标库的查询窗口执行即可。

这项功能在数据量小的时候很好用，比如配置表、字典表，几百行数据几秒钟就挪过去了。但是要注意：数据量大就别用这个方式。我有一次复制一张二十万行的日志表，Navicat 直接把 INSERT 语句拼接成一个超长文本，再执行的时候不仅内存吃紧，SQL 编辑器的渲染也明显卡顿。超过两三万行，建议直接用「数据传输」工具，在表之间做批量搬运，或者导出 CSV 再导回。

4.3 执行 SQL 语句：查询窗口里的几个顺手用法

执行 SQL 是常规操作，但有几个使用习惯值得说一下。第一个，Navicat 的查询窗口可以只执行选中的部分语句，不用每次都把整个脚本跑一遍。调试 SQL 的时候，我只选中要处理的那一段再按运行，避免把前面建临时表的语句重复执行。第二个，如果脚本里有事务，记得在窗口顶部写好BEGIN;和COMMIT;，Navicat 不会帮你自动包事务。第三个，删除或更新操作前先执行同条件的 SELECT，确认影响范围，我吃过一次没写 WHERE 条件的亏，从那以后 UPDATE 和 DELETE 前必定先查一眼。

-- 先看影响行数，再加 WHERE 执行 UPDATE select count(*) from business_order where status = 'F';

这条 SQL 本身没有特别之处，但养成先 count 再 update 的习惯，在迁移数据时可以帮你少出几次事故。

4.4 转储前用 Navicat 自查一下源库状态

在正式的转储操作前，我通常会先检查三件事：数据库连接是否空闲、有没有长事务在跑、表数量是否和预期一致。金仓和 PostgreSQL 一样，pg_stat_activity系统表能直接查到后台会话，Navicat 里有对应的「进程列表」查看面板。如果发现别的会话占着锁，转储出来的数据可能是某个旧快照，容易导致导出的数据不完整。自查这一步不是必须，但对于生产库的备份操作，多花两分钟换一份可靠的数据文件，值得。

5. 避坑与常见问题：连接失败、乱码和权限的五个现场

5.1 端口填 5432，一直提示无法连接

现象：Navicat 测试连接，提示connection refused或者超时，服务端明明已经启动。 原因：人大金仓默认监听端口是 54321，很多同事以前连的是 PostgreSQL，惯性把端口写成 5432。另外金仓如果部署在 Docker 里，容器端口映射可能把 54321 映射成了宿主机的另一个端口，需要先用docker port确认实际对外端口。 解决：确认服务端配置文件里的port参数，金仓的配置文件一般在安装目录的data下；Docker 环境则用docker ps查看端口映射。修改后重新测试连接。

5.2 连接成功但中文显示乱码

现象：Navicat 里查询出来的中文全是乱码，或者在 Navicat 里写入的中文，到业务系统里读出来是乱码。 原因：客户端连接编码和数据库字符集不一致。数据库端是 UTF8，Navicat 连接的高级选项中编码没设置或设成了 GBK，字节流在客户端被错误解码。 解决：编辑连接，在高级选项卡里把编码改为 UTF-8。另外检查一下连接初始化语句里有没有执行过SET NAMES，金仓兼容 PG 协议，不需要也不建议执行 MySQL 风格的SET NAMES，保持连接编码和库编码一致即可。

5.3 连接成功但转储 SQL 时报权限不足

现象：数据库可以正常访问，右键转储 SQL 文件时弹出permission denied for schema xxx。 原因：当前账号对要转储的对象没有对应权限。金仓的权限模型继承自 PG，连接权限和对象权限是分开的，能连上不代表能导出。 解决：在源库上对账号授权，或者直接使用具备超级权限的账号执行转储。临时授权的命令是：

grant usage on schema public to your_user; grant all on all tables in schema public to your_user;

注意后面这条只对有ALL TABLES的节点生效，新建的表需要再授权一次，如果不想逐张处理，可以授权给该用户的默认权限。

5.4 复制为插入语句操作大表，Navicat 卡死

现象：选中几万行数据执行「复制为插入语句」，软件长时间无响应。 原因：Navicat 要先把所选行拼成一个完整的 SQL 文本，行数多、字段多时拼接耗时和内存占用都会暴涨，界面等待反馈不及时，观感就是卡死。 解决：小表用复制为插入语句，大数据量改用「数据传输」向导，把源表直接同步到目标库，或者导出成 CSV 再导入。操作前先选中目标行数较少的数据，避免全选。

5.5 旧版本 Navicat 连接报认证协议错误

现象：连接金仓时报unsupported frontend protocol或者password authentication failed，但密码肯定是正确的。 原因：金仓低版本或特殊编译版本对认证方式的支持和老版 Navicat 使用的 PG 驱动不完全兼容；另外金仓在安装时如果选了特定加密方式，老驱动可能不认识。 解决：优先确认金仓服务端pg_hba.conf中的认证方式，建议使用md5或scram-sha-256，金仓默认支持这两类。然后升级 Navicat 到较新版本，新版本内置的 PG 驱动对这两种认证方式支持更稳定。不要在这时候去调金仓的加密算法，除非你能确认所有客户端都同步升级。

6. 验证连接与进阶操作：把 Navicat 用成金仓的稳定入口

连接配置完成、数据库也建好了，很多人觉得"能连上就行"，但我建议新环境第一次上手时，走一遍验证流程，把不确定性留在初始阶段，别等到交付前夜再暴露问题。

第一步是验证版本和编码环境。在 Navicat 的查询窗口执行：

select version();

金仓环境下返回的结果会包含KingbaseES字样和版本号，顺便看一眼返回结果里的字符集信息是否和预期一致。第二步是例行巡检三张视图：pg_database看库级编码和排序规则，pg_stat_activity看是否有长事务，pg_tables看表数量是否对得上。这套组合我一般每次接新环境都跑一遍，时间成本不到三分钟，但能把字符集不一致、事务残留、缺表漏表这几类坑提前排除。

进阶一点，可以把常用操作存成 Navicat 的查询文件。比如把「查会话、查锁、查表大小、查阻塞」四段 SQL 存成一个巡检.sql文件，以后每次进环境只需要打开这个文件，改一下库名就能跑。Navicat 的查询窗口支持多语句同时执行，结果集分别展示，比一条条敲要快得多。

还有一个习惯值得推荐：把 Navicat 和金仓自带工具配合使用，而不是二选一。我用 Navicat 做开发和日常运维，因为它对 PostgreSQL 协议兼容得确实顺；但遇到服务端资源占用异常或者底层配置修改的场景，我会切到金仓自带的管理工具去看节点状态。两个工具读的是同一个数据库，并不冲突。

回到这条连接本身，配置一次固定下来之后，Navicat 就成了我面对金仓的稳定入口。从那以后我每接一个金仓环境，第一件事就是检查端口、编码、排序规则三件套，确认无误再开始导入数据，再没有出现过首次交付时的乱码和排序翻车。希望帮到你。

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