Navicat连接人大金仓：字符集与排序规则迁移避坑指南

简介《使用Navicat连接人大金仓》是一份面向数据库运维、开发及迁移实施人员的中文操作指南聚焦借助Navicat图形化工具连接人大金仓并完成日常管理的典型场景适合需要快速上手跨库连接、建库与SQL执行的学习者。资源包共1个docx文档大小约1.62MB内容按目录组织依次覆盖Navicat下载安装、连接创建与账号密码配置、连接成功后的对象查看、数据库创建、SQL文件转储、复制为插入语句及SQL语句执行等模块并补充字符集与排序规则、账号权限和官方工具选用等注意事项便于按步骤查阅和对照练习。该文档已有约1300人学习可帮助读者建立从连接到管理的完整操作路径降低迁移与运维中乱码、连接失败等问题的排查成本。1. Navicat 连人大金仓真正让人翻车的不是连接串是那行排序规则用 Navicat 连接人大金仓KingbaseES这件事第一次做的人多半觉得十分钟能收工装个客户端、填个 IP 和端口、点一下测试连接绿灯一亮就完事。真到现场才发现卡人的从来不是连接串——是建库时那一行排序规则。金仓自带图形工具建出来的库排序规则默认是 zh_CN.UTF-8 这类区域化设置Navicat 这边建库时如果顺手选了另一套库照样能建、表照样能写、中文照样能插等到迁移跑一半才发现order by的顺序跟老系统对不上、唯一索引判重结果不一致、导出的 SQL 再导回去整列变问号。这种坑不会在连接成功那一刻报错属于典型的“看着通了其实没通”。这篇记录写给两类人一类是刚接手金仓、手上只有 Navicat 这一把图形化工具的开发另一类是正在做库迁移需要把 SQL 从旧库倒出来再灌进金仓的运维。装什么版本、连接类型选哪个、字符集在哪一栏改、转储失败怎么救下面按顺序走一遍。2. 装前把环境列清Navicat 版本、金仓端口与客户端字符集装数据库客户端最容易犯的错是先双击安装包再想环境。Navicat 这类工具装起来不复杂真正决定后面顺不顺的是三件事客户端版本对不对得上服务端协议、端口是不是金仓那个特殊值、库的编码和排序规则心里有没有数。这三样没摸清就动手后面每一步都在猜。2.1 版本取舍navicat161_premium_cs_x64 与金仓的协议兼容金仓走的是 PostgreSQL 协议族Navicat 里没有“Kingbase”这个独立选项所以客户端选型时只看它对 PG 协议的支持程度。我一般直接上 Navicat Premium不用 Navicat for PostgreSQL——不是因为功能多而是迁移项目里往往同时挂着 MySQL 老库和金仓新库一个客户端来回切比装两个省事连接配置、查询历史都集中在一处。版本上原文给的是navicat161_premium_cs_x64.exe16.1 的简体中文 64 位安装包。文件名拆开看161是版本号premium是 Premium 版cs是 Chinese Simplified 界面x64是 64 位。装 32 位包在 64 位系统上也能跑但处理大结果集时内存上限明显吃紧几十万行的表一查就卡所以能上 64 位就上 64 位。注意Navicat 的小版本之间对较新 PG 协议的支持是有差别的。如果你连的金仓版本比较新客户端却停在很老的 12.x可能出现连上了但元数据列表刷不出来、函数和类型识别不全的情况。装之前先确认自己下的是 16.x 这一档。金仓那边的版本号原文没写也不建议照抄别人的。落地前先在服务端执行一次select version();把版本串记到部署笔记里后面出问题对日志时用得上。2.2 三分钟摸清现场端口、编码、账号权限这一段是我每次装完客户端、还没点“新建连接”之前必做的一轮摸底。摸底盘的是服务端不是客户端目的是让后面每一步填的参数都有依据。检查项怎么查期望结果服务是否在监听nc -zv 主机 端口端口可达不是 connection refused实际端口服务端kingbase.conf里的port项金仓常见是 54321不是 PG 的 5432服务端编码show server_encoding;UTF8库排序规则查pg_database的datcollate/datctype与迁移源库保持一致账号权限是否能建库、目标 schema 是否有 CREATE 权限建库账号需具备 CREATEDB# 1) 先探端口通了说明服务在听不通就别怀疑客户端了 nc -zv 10.0.0.21 54321 # 2) 用金仓自带客户端确认编码ksql 一般随服务端一起装 ksql -h 10.0.0.21 -p 54321 -U system -d test -c show server_encoding; # 3) 把每个库的编码和排序规则一次列出来迁移前必看 ksql -h 10.0.0.21 -p 54321 -U system -d test \ -c select datname, pg_encoding_to_char(encoding) as enc, datcollate, datctype from pg_database;三条命令的逻辑是递进的第一条只验证网络层和服务进程排除防火墙和端口写错第二条确认服务端字符集UTF8 是后面不乱码的前提第三条把库里最容易被忽略的两列——datcollate排序规则和datctype字符分类——摊开来看这两列就是原文反复强调的“排序规则和字符分类在迁移库一致”落到的具体字段。参数上-p是最容易写错的一个。很多人凭 PostgreSQL 的肌肉记忆填 5432连接直接超时然后开始怀疑账号、怀疑防火墙、怀疑驱动其实只是端口差了一位数。-U用的账号要跟后面 Navicat 里填的保持一致否则你在客户端里看到的现象和命令行里对不上排查时会绕远路。3. 安装 Navicat Premium从安装包到第一次启动环境摸清之后才轮到装客户端。这一步本身不难难在装完之后环境不干净——装到一半被拦截、装完打不开、重装时旧配置没清导致新版本一启动就报错。下面按安装顺序拆。3.1 下载与安装包确认官方下载页在navicat.com.cn/download/navicat-premium进页面后选 Windows 平台、x64、Premium 版下下来的文件名应该就是navicat161_premium_cs_x64.exe。文件名对不上说明你点错了版本或者页面默认给你推了别的产品线。下载完别急着双击先做一次完整性确认。安装包在传输过程中被截断的情况不常见但确实有表现是双击后安装向导一闪就退或者装到 70% 报“安装文件损坏”很容易被误判成系统问题。# Windows 下算一遍 SHA256跟下载页或内网镜像登记的值对一下 certutil -hashfile navicat161_premium_cs_x64.exe SHA256certutil是 Windows 自带的证书工具-hashfile后面跟文件路径SHA256是算法。输出是一串十六进制摘要跟你手上登记的值逐位比对即可。对不上就重下别抱侥幸——用坏包装出来的客户端后面出什么怪问题都不奇怪。内网环境没法直连下载页的话常见做法是把安装包放到内部文件服务器同时在旁边放一个.sha256文本谁装谁自己校验。这个习惯看着多余等哪天真碰上坏包它就是省下两小时的那一步。3.2 安装向导里值得停一下的两个选项双击安装包后基本是一路下一步但有两处值得停下来。第一处是安装路径。默认路径在C:\Program Files\PremiumSoft\Navicat Premium 16本身没问题别自作主张改到中文目录或者带空格的深层目录下。Navicat 自身跑起来没事但它调用外部工具、写临时文件、导出大 SQL 的时候路径里的中文和空格是经典的翻车点尤其是导出到桌面这种带中文用户名的路径。第二处是安装过程中的安全软件拦截。Navicat 安装时会往系统里注册文件关联、写注册表、装服务组件某些安全策略比较严的机器上会被静默拦掉一部分表现是安装向导显示“完成”但开始菜单里找不到图标或者点开报缺少 DLL。真遇上这种情况正确做法是退出安装、把安全软件对安装目录加白、重新跑一遍安装包而不是去网上找 DLL 单独补。装完之后先在“帮助 → 关于”里看一眼版本号确认是 16.1。这一步是为了排除“装了两个版本、点开的是旧的那个”这种低级但高频的问题——尤其是机器上以前装过 Navicat 试用版或者别的产品线快捷方式重名很常见。提示重装之前一定要先卸载干净。Navicat 的连接配置、查询历史、外观设置放在用户目录下一般是文档\Navicat加上注册表HKEY_CURRENT_USER\Software\PremiumSoft一带只删安装目录会留下旧配置新版本启动时读到不兼容的配置项会出现界面打不开、连接列表空白这类现象。要彻底重来卸载后手动清掉这两处再装。3.3 首次启动把自动更新和界面语言处理掉第一次启动会弹试用提示按实际情况处理即可。真正需要动的是两处设置。一处是自动更新。内网机器上让它去连更新服务器轻则每次启动卡十几秒重则弹一堆网络错误对话框干扰判断。在“工具 → 选项 → 常规”里把自动检查更新关掉手动升级的节奏自己控。另一处是界面语言。装的是cs包默认就是简体中文一般不用改。但如果机器上装过英文版语言设置可能被继承下来出现菜单一半中文一半英文的情况看着难受且容易点错菜单位置。在选项里确认一下语言是“简体中文”改完重启生效。到这一步客户端就算装好了但还不算“能用”。下一步才是整篇最关键的地方连接参数的填法。4. 新建连接连接类型、字符集与建库参数怎么填Navicat 装完之后的大部分坑都集中在这一章。连接类型选错后面全白搭字符集那一栏不填中文乱码只是时间问题建库时的排序规则随手一点迁移做完才发现对不上。下面按“建连接 → 填认证 → 建库 → 导数据 → 跑 SQL”的顺序走。4.1 连接类型别选错金仓走 PostgreSQL 协议打开 Navicat左上角“连接 → 新建连接”弹出的类型列表里有 MySQL、Oracle、PostgreSQL、SQLite、SQL Server、MariaDB、MongoDB 这些。金仓不在列表里这是正常的它对外走 PostgreSQL 协议所以选PostgreSQL。选 MySQL 或 Oracle 连不上会直接报协议握手失败别在这个地方浪费时间去调参数。连接名建议全英文比如kingbase_prod、kingbase_test。原因很实在Navicat 转储 SQL 文件时默认拿连接名或库名当文件名中文名在某些解压工具、某些脚本处理环节里会变成乱码导出的.sql在别人机器上打不开排查半天才发现是文件名的问题。主机填服务端地址端口填54321——金仓的常见默认值跟 PostgreSQL 的 5432 差一位是这一章最容易写错的地方。初始数据库可以先填test或system连上之后再切换。4.2 账号密码与客户端字符集在同一个对话框的“认证”区域填用户名和密码。账号信息一般由服务端管理员提供填错的表现是连接测试报认证失败这个提示很明确不用多猜。真正需要手动干预的是字符集。切到“高级”或“其他参数”页找到客户端的字符集/编码一项设成UTF8。Navicat 有些版本默认跟随系统区域设置在中文 Windows 上可能落到 GBK 一类的编码上表现是连接正常、表能打开、数据也能看但中文列显示成问号或者导出的 SQL 里中文变成一串转义。注意字符集这一栏填的是“客户端编码”它跟服务端编码、跟建库时的编码是三件不同的事。客户端填 UTF8 只保证这次会话传输不乱码建库时的编码和排序规则是写进库里的、跟着数据走的。两者都得对缺一个都会在某个环节露馅。填完点“测试连接”绿灯之后再点确定保存。如果测试失败先按第 5 章里的连接类问题逐条排别反复改密码。4.3 建库时把编码和排序规则钉死C 还是 zh_CN.UTF-8这一步是整篇的核心。原文那句“排序规则和字符分类在迁移库一致否则会出现乱码建议使用 C”信息量很大拆开讲。金仓自带图形工具建库时排序规则默认落在zh_CN.UTF-8这一类区域化设置上中文的排序、比较会按区域习惯走。Navicat 建库时如果选了C排序就退化成纯字节序比较快、结果确定、跨平台一致但中文按字节排出来的顺序跟拼音顺序对不上。两边不一致会发生什么order by name的结果不同、唯一索引判定的重复不同、某些字符串比较函数的返回值不同。数据本身没坏坏的是你依赖顺序和比较结果的那些业务逻辑这类问题最难查。我的处理原则是跟源库一致。迁移场景下源库是什么排序规则新库就建什么别自作主张“优化”成 C。源库是zh_CN.UTF-8就建zh_CN.UTF-8源库本身就是 C那就建 C。只有一种情况我会主动选 C——新建的、没有历史包袱的、纯做数据落地的库选 C 最省心。建库时别依赖 Navicat 对话框里的默认值用 SQL 显式写死-- 显式钉死编码与排序规则不依赖客户端默认值 create database demo_db with encoding UTF8 lc_collate C lc_ctype C template template0;逐项说encoding UTF8是库级编码建完不能改写错了只能重建lc_collate管排序lc_ctype管字符分类大小写转换、正则字符类这些两者最好一起设成同一个值template template0是关键参数template1可能带着上一个库的排序规则和扩展对象下来用template0才是干净起点。这几项在库建好之后就固定了改的成本相当于重建整个库所以建之前多花三十秒确认。如果源库是区域化排序把上面两句换成lc_collate zh_CN.UTF-8、lc_ctype zh_CN.UTF-8encoding保持 UTF8。建完用 4.2 里那条查pg_database的语句回读一遍确认落库的值跟你要的一致别只信对话框。4.4 转储 SQL 文件与复制为插入语句库建好、连接正常之后接下来是数据的进出口Navicat 在这块给了两个很实用的功能。转储 SQL 文件用于整库或整表备份/迁移。右键目标库或表 → “转储 SQL 文件” → 选“结构和数据”或“仅结构” → 指定路径和文件名 → 开始。我的习惯是先只转结构、确认 DDL 能在新库跑通再分表转数据。原因是大库一次性带数据转储跑到一半超时或内存不够前面几十分钟白等而且失败点不好定位。复制为插入语句用于小批量搬数据。在结果集里选中若干行右键“复制为插入语句”剪贴板里拿到的就是一串可以直接执行的 INSERT。粘出来长这样-- 从复制为插入语句粘出来的结果注意双引号包裹的标识符 INSERT INTO public.t_user (id, name, created_at) VALUES (1, 张三, 2024-05-01 10:00:00); INSERT INTO public.t_user (id, name, created_at) VALUES (2, 李四, 2024-05-01 10:05:00);这里有个跨库迁移的细节PG 系用双引号包标识符粘到金仓里没问题如果目标端是 MySQL双引号得换成反引号否则直接语法错误。另外几千行以上的 INSERT 别一次性粘进编辑器执行分批提交不然事务日志涨得很快机器差一点的直接卡死。4.5 在 SQL 编辑器里跑第一条语句工具栏上点“查询 → 新建查询”或者直接按快捷键开 SQL 编辑器。跑之前先分清两个动作“运行已选择”和“运行全部”。编辑器里堆了十几条语句时光标停在哪一行、选中了哪一段执行结果完全不同误操作在正式库上是会出事的。连上之后的第一条语句建议固定跑这一组-- 连上就先看这三样确认连接落在预期的库和编码上 select version(); show server_encoding; select datname, pg_encoding_to_char(encoding) as enc, datcollate, datctype from pg_database where datname current_database();version()打出服务端版本串server_encoding是服务端编码第三条返回当前库的编码、排序规则、字符分类。三条结果跟你第 2 章摸底时记下的值逐项对一遍对得上说明客户端和服务端在同一个认知上。5. 避坑与排查连接、乱码、转储这四类问题怎么救装环境这件事能一次走通是运气卡住才是常态。下面四条是我在 Navicat 连金仓这条路上踩得最实的按“现象 → 原因 → 解决”记遇到时按顺序对号。5.1 连接类测试连接失败的三种典型表现现象一测试连接转圈十几秒后报超时。原因多半是端口写错或者网络不通不是账号问题。金仓默认端口 54321很多人按 PostgreSQL 习惯填 5432。解决先用nc -zv 主机 54321探一下端口不通就去找网络和防火墙别在客户端里反复改参数。现象二报认证失败。账号密码错了是一种但更常见的是账号存在、权限不够或者服务端的认证配置文件金仓里通常是sys_hba.conf这一类没放行你这台机器的 IP。解决先用同一个账号在服务端用ksql连一次命令行能连、Navicat 不能连问题在客户端配置命令行也连不上问题在服务端认证规则。现象三连上了但左侧展开是空的看不到任何表。原因通常是search_path没覆盖到你想要的 schema或者这个账号在目标 schema 上没有 USAGE 权限。解决在 SQL 编辑器里执行show search_path;看当前路径再执行select table_schema, table_name from information_schema.tables where table_schema not in (pg_catalog,information_schema);直接查元数据能查到就说明表在、只是客户端没展示去连接属性里把默认 schema 指过去。5.2 编码类中文变问号的两个源头现象表能打开中文列显示成???或者方块。原因在客户端编码不是你数据坏了。连接属性里的客户端字符集没设成 UTF8会话按 GBK 一类编码解释字节流自然对不上。解决断开连接改连接属性里的字符集为 UTF8重连再看。改完还是乱说明数据在写入时就已经坏了往上看下一条。现象数据写入正常导出 SQL 再导回新库后中文全乱。原因是建库时的编码或排序规则跟源库不一致典型的是一边 UTF8 一边别的编码或者排序规则一个 C 一个 zh_CN.UTF-8。解决这种没法靠改客户端救只能按 4.3 的方式建一个跟源库一致的新库把数据重新导一遍。所以建库那一步宁可多花时间确认也不要建完再返工。提示判断乱码发生在哪一层有个简单办法——在 SQL 编辑器里执行select length(中文测试), 中文测试;。长度对、显示乱是客户端显示问题长度也不对是存储层编码问题。这一条能把排查范围砍掉一半。5.3 转储类SQL 文件跑到一半失败现象转储进度条走到某个百分比报错中断文件只有半截。原因通常是表里有超大字段长文本、二进制大对象或者单表行数太多撑爆了内存也可能是导出路径在中文目录下、磁盘空间不够。解决先只转结构确认 DDL 没问题再按表分批转数据大字段的表单独处理导出路径换成纯英文短路径比如D:\dump\别用桌面。现象转储出来的 SQL 在新库执行时报“关系不存在”。原因是导出的脚本里带了 schema 前缀而新库没有对应的 schema。解决导入前先在新库把 schema 建好或者转储时在高级选项里去掉 schema 限定。这类报错信息很明确照着缺什么补什么就行不用大改。5.4 执行类SQL 跑出来结果跟老系统对不上现象同样的order by两边排出来的顺序不同。原因就是第 4.3 说的排序规则不一致C按字节排、zh_CN.UTF-8按区域习惯排中文数据上差异非常明显。解决确认源库排序规则重建目标库为一致的值重导数据。如果业务已经跑起来不方便重建退一步的办法是在 SQL 里显式写排序表达式但这只是绕过不是修好。现象编辑器里执行没反应也不报错。多半是没选中语句或者光标停在空行上执行了空内容。解决确认选中范围或者用“运行全部”。这个坑太低级但每个月总有那么几次。6. 装完怎么验证三步把连接、编码、转储全跑一遍装完、连上、能看见表这只是“看起来通了”。真正能交付的状态是编码对得上、中文能往返、转储出来的 SQL 能导回另一个库并保持一致。我一般用三步验证半小时内能跑完跑完才敢跟人说环境好了。第一步元数据核对。把版本、服务端编码、当前库的排序规则一次性打出来跟摸底时记的值贴在一起存档-- 存档用版本 编码 排序规则三件套 select version() as server_version; show server_encoding; select datname, pg_encoding_to_char(encoding) as enc, datcollate, datctype from pg_database where datname current_database();第二步中文往返。这一步专门用来暴露排序规则不一致的问题因为中文的排序结果是最敏感的探针-- 中文字段 排序排序规则不对时这里的顺序会跟源库不一样 create table t_check (id int primary key, name varchar(50)); insert into t_check values (1, 张三), (2, 李四), (3, 王五); select * from t_check order by name; select count(*) from t_check where name like %张%;建表、插入中文、按中文排序、做一次模糊匹配四件事都正常说明客户端编码、库编码、字符分类这三层是对齐的。顺序跟源库一致说明排序规则也对了。有一条不对回到 4.3 检查建库参数。第三步转储回环。把刚才那张小表转储成 SQL 文件新建一个临时库把文件导进去对比行数和内容验证项操作通过标准结构可导出右键表 → 转储 SQL 文件 → 仅结构文件生成DDL 无语法错误数据可导出同一入口选结构与数据文件行数与表行数一致可回导新建临时库 → 运行 SQL 文件无报错表创建成功内容一致select count(*)两边对比行数相同中文不乱码三步都过这套 Navicat 连金仓的环境就算立住了。以后换机器、重装客户端照这三步再跑一遍不用重新摸索。从那以后我每次装完 Navicat 连金仓都强制先把这三步走一遍才往业务上接——血泪经验是有一回省了第三步结果转储文件里字段顺序跟源表不一致数据灌进去错位了两列查了一整天才定位到是导出选项的问题。环境这东西验证花的那半小时永远比事后救火便宜。希望帮到你。本文还有配套的精品资源点击获取