简介面向需要通过 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 类型连接是官方之外最常见也最稳的接法。选完类型后弹出连接参数窗口需要填的信息有连接名、主机、端口、初始数据库、用户名、密码。关键参数我列个表对照参数填什么说明连接名任意如“金仓测试库”只在当前机器显示不发送给服务端主机金仓所在 IP 或 localhost本机连接填 localhost远程连接填 IP端口54321人大金仓默认端口Navicat 默认 5432 必须改初始数据库填一个已存在的库如 TEST不填也能连填了可以提前验证库权限用户名安装金仓时设置的超级用户默认一般是 system密码是安装时设置的最容易踩的是端口。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 文件再新建一个空库运行刚才转储的文件确认数据完整。这一步能验证转储和执行两个方向都正常也能顺带检验排序规则在真实数据上的表现。从那以后我每次拿到一套新的金仓环境都强制自己把这五步完整走一遍大约十分钟。别小看这十分钟它能在一开始就把端口、权限、字符集的问题全暴露出来省得后面迁数据迁到一半才发现连不上进退两难。希望这套验证流程帮到你少走我当年走过的弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?