简介面向需要连接与管理人大金仓数据库的开发、运维及数据迁移人员这份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 里填。现场临时问人十有八九会漏掉模式那一条。参数常见取值说明出错后的表现主机实例 IP 或域名同机部署也别写 localhost容易连到本机另一套实例连接超时或拒绝端口54321出厂默认不是 PostgreSQL 的 5432这是最高频的错测试连接超时初始数据库业务库名如appdb留空会落到默认库看起来像「库不见了」对象树里没有业务表用户名出厂常见system生产另建超级用户能绕过权限问题但也掩盖权限问题认证失败或看不到对象模式 schemapublic或业务自建模式人大金仓的对象挂在模式下不切就看不到表连上了但表列表为空端口这一条值得单说。PostgreSQL 的默认端口是 5432Navicat 新建 PostgreSQL 连接时也会把 5432 预填进去而人大金仓出厂默认监听 54321。两边默认值不一样填的时候又不显眼于是就成了我见过最多的「连不上」原因。拿到实例后先确认kingbase.conf里port的实际值或者直接问 DBA 要一句准话别信记忆。2.3 客户端环境连通性、防火墙与编码Navicat 装在本机库在服务器上中间隔着防火墙和安全组。装之前先做一次连通性测试把「网络问题」和「Navicat 配置问题」分开后面排错能省一半时间。# Windows 上先确认端口通不通排除 Navicat 背锅 Test-NetConnection -ComputerName 192.168.10.21 -Port 54321TcpTestSucceeded : 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应该是UTF8datcollate和datctype记下来建新库时要么跟它一样要么明确知道自己为什么不一样。4. 建库、字符集与数据进出乱码和导入报错都出在这一步连接通了只是开始真正决定这套环境能不能长期用的是字符集和排序规则。这一章把建库、转储、执行脚本串起来写因为它们的失败往往是同一个原因。4.1 用 Navicat 新建数据库时那几个下拉框在连接名或者已有库上右键「新建数据库」弹窗里除了库名还有编码、排序规则collation、字符分类ctype三个下拉框以及一个模板选择。-- 等价于在查询窗口直接建库参数看得更清楚 CREATE DATABASE appdb WITH ENCODING UTF8 LC_COLLATE C LC_CTYPE C TEMPLATE template0;三个参数的含义ENCODING决定字符怎么存只要业务有中文就应该是UTF8LC_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。对比项Czh_CN.UTF-8中文排序按字节序不是拼音序按拼音序符合业务直觉建库成功率任何环境都能建目标机缺 zh_CN locale 时会失败跨平台迁移最稳不依赖系统区域设置换机器可能要重新装 locale索引行为稳定字节比较可预测依赖 locale 实现版本间可能有差异常见来源手工建库、迁移规范人大金仓自带图形工具默认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;读回来还是「中文落库验证」说明客户端编码、库编码、连接编码三处是一致的。这一步别省乱码问题在空库上永远发现不了等到业务数据灌进去再发现清理成本完全不是一个量级。第三层验数据链路。拿一张有代表性的业务表走一遍「转储 → 在另一个库导入 → 比对行数」的完整流程验证项命令或操作通过标准源表行数SELECT count(*) FROM t_order;记下数字转储文件编码用文本编辑器打开看中文不是问号、不是乱码目标表行数导入后同样执行count(*)与源表一致中文抽样随机取几行看字段值与源端逐字相同排序抽查ORDER BY一个中文字段结果顺序符合预期三层全过这套连接才算真正可用。我吃过一次亏连接测试通过、中文探针也正常结果转储文件在目标库导入时因为排序规则不同唯一索引冲突报了一堆重复键错误业务侧等到第二天早上才发现。从那以后我每次接新库都强制把这三层验证走一遍尤其是第二层的乱码探针和第三层的行数比对哪怕 DBA 说「这库刚建的没问题」也照走不误。装环境这件事后悔药从来都是提前吃的。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/31 11:23:46 · 阅读 1.2k Navicat连接人大金仓：端口、编码与转储避坑指南
简介面向需要连接与管理人大金仓数据库的开发、运维及数据迁移人员这份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 里填。现场临时问人十有八九会漏掉模式那一条。参数常见取值说明出错后的表现主机实例 IP 或域名同机部署也别写 localhost容易连到本机另一套实例连接超时或拒绝端口54321出厂默认不是 PostgreSQL 的 5432这是最高频的错测试连接超时初始数据库业务库名如appdb留空会落到默认库看起来像「库不见了」对象树里没有业务表用户名出厂常见system生产另建超级用户能绕过权限问题但也掩盖权限问题认证失败或看不到对象模式 schemapublic或业务自建模式人大金仓的对象挂在模式下不切就看不到表连上了但表列表为空端口这一条值得单说。PostgreSQL 的默认端口是 5432Navicat 新建 PostgreSQL 连接时也会把 5432 预填进去而人大金仓出厂默认监听 54321。两边默认值不一样填的时候又不显眼于是就成了我见过最多的「连不上」原因。拿到实例后先确认kingbase.conf里port的实际值或者直接问 DBA 要一句准话别信记忆。2.3 客户端环境连通性、防火墙与编码Navicat 装在本机库在服务器上中间隔着防火墙和安全组。装之前先做一次连通性测试把「网络问题」和「Navicat 配置问题」分开后面排错能省一半时间。# Windows 上先确认端口通不通排除 Navicat 背锅 Test-NetConnection -ComputerName 192.168.10.21 -Port 54321TcpTestSucceeded : 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应该是UTF8datcollate和datctype记下来建新库时要么跟它一样要么明确知道自己为什么不一样。4. 建库、字符集与数据进出乱码和导入报错都出在这一步连接通了只是开始真正决定这套环境能不能长期用的是字符集和排序规则。这一章把建库、转储、执行脚本串起来写因为它们的失败往往是同一个原因。4.1 用 Navicat 新建数据库时那几个下拉框在连接名或者已有库上右键「新建数据库」弹窗里除了库名还有编码、排序规则collation、字符分类ctype三个下拉框以及一个模板选择。-- 等价于在查询窗口直接建库参数看得更清楚 CREATE DATABASE appdb WITH ENCODING UTF8 LC_COLLATE C LC_CTYPE C TEMPLATE template0;三个参数的含义ENCODING决定字符怎么存只要业务有中文就应该是UTF8LC_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。对比项Czh_CN.UTF-8中文排序按字节序不是拼音序按拼音序符合业务直觉建库成功率任何环境都能建目标机缺 zh_CN locale 时会失败跨平台迁移最稳不依赖系统区域设置换机器可能要重新装 locale索引行为稳定字节比较可预测依赖 locale 实现版本间可能有差异常见来源手工建库、迁移规范人大金仓自带图形工具默认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;读回来还是「中文落库验证」说明客户端编码、库编码、连接编码三处是一致的。这一步别省乱码问题在空库上永远发现不了等到业务数据灌进去再发现清理成本完全不是一个量级。第三层验数据链路。拿一张有代表性的业务表走一遍「转储 → 在另一个库导入 → 比对行数」的完整流程验证项命令或操作通过标准源表行数SELECT count(*) FROM t_order;记下数字转储文件编码用文本编辑器打开看中文不是问号、不是乱码目标表行数导入后同样执行count(*)与源表一致中文抽样随机取几行看字段值与源端逐字相同排序抽查ORDER BY一个中文字段结果顺序符合预期三层全过这套连接才算真正可用。我吃过一次亏连接测试通过、中文探针也正常结果转储文件在目标库导入时因为排序规则不同唯一索引冲突报了一堆重复键错误业务侧等到第二天早上才发现。从那以后我每次接新库都强制把这三层验证走一遍尤其是第二层的乱码探针和第三层的行数比对哪怕 DBA 说「这库刚建的没问题」也照走不误。装环境这件事后悔药从来都是提前吃的。希望帮到你。本文还有配套的精品资源点击获取