简介针对使用Navicat连接人大金仓数据库这一常见需求这份资源提供了一份图文并茂的docx操作指南适合需要管理人大金仓数据库的运维人员、开发者以及数据库初学者参考。文档从Navicat的下载安装讲起详细梳理了创建连接、配置账号密码、新建数据库、转储SQL文件、复制为插入语句以及执行SQL语句的完整流程并结合实际操作强调了字符集与排序规则需与目标库保持一致等关键注意事项帮助读者避开乱码等典型坑点。通过学习读者可以独立完成Navicat与人大金仓的连接配置并顺利开展数据查询、备份与迁移等日常维护工作。资源为单一docx文档大小仅1.62MB内容紧凑、步骤清晰便于随时查阅对照。目前已有1291人学习下载是一份实用性很高的小体积速查资料。1. 使用 Navicat 连接人大金仓先说为什么值得用使用 Navicat 连接人大金仓本质上是拿 Navicat 的 PostgreSQL 连接器去和金仓的 PG 兼容接口握手。很多从 Oracle、MySQL 迁到人大金仓的团队第一反应是用金仓自带的图形工具或命令行 psql。单条查询、简单建表没问题但一旦涉及数据对比、结果集编辑、批量导入导出、生成插入语句自带工具的效率就明显掉队。Navicat 是支持 MySQL、Oracle、PostgreSQL、SQL Server、MariaDB 等多类数据库的通用管理工具界面统一、操作路径成熟、文档多几乎是迁移项目里最省心的选择。这篇按实际落地顺序走一遍版本选择、安装驱动、建连、建库、转储 SQL、复制为插入语句、执行脚本重点讲排序规则和字符集不一致导致的乱码问题。2. 连接前的准备版本、安装与连接参数的填写要点2.1 Navicat 版本怎么选Premium 与专用版的边界Navicat 家族按数据库类型拆得很细有 Navicat for MySQL、Navicat for PostgreSQL、Navicat for Oracle还有把多类型合并的 Navicat Premium。连人大金仓时我一般建议直接装 Premium而不是选 for PostgreSQL 专用版原因有两点。第一人大金仓的 SQL 方言基于 PostgreSQL 演进但 Navicat 官方支持列表里不会专门写人大金仓这个类型实际操作是用 PostgreSQL 连接器连的。Premium 和 for PostgreSQL 在连接器层面没有区别但 Premium 同时管理 MySQL、Oracle、SQL Server 等其他库。数据迁移场景里源库往往是 MySQL 或 Oracle目标库是金仓用 Premium 可以把源库和目标库挂在同一个连接树里点两下就能切换对比省掉开多个工具的麻烦。第二Premium 的数据传输和结构同步功能支持跨数据库类型。比如把 MySQL 某张表直接同步到人大金仓Navicat 会自动做类型映射并建表。for PostgreSQL 版本没有这个能力。如果你手头只有金仓一个库用 for PostgreSQL 也够但以后大概率会碰到别的库一步到位装 Premium 更划算。版本号选 16 及以上。Navicat 16 的界面布局、连接配置项都比较完善社区里遇到的问题也基本都有答案。Navicat 17 增加了团队协作类功能单人使用差异不大。公司有授权就用授权版本个人学习用官网试用版也能完成全部操作功能上不会限制本文涉及的内容。2.2 下载安装与驱动初始化装错版本和杀毒干扰安装包从官网下载最稳妥。Windows 平台常见的文件名是 navicat161_premium_cs_x64.exe这里的信息可以拆开理解161 表示 16 大版本下的第一个迭代cs 表示简体中文语言包x64 表示 64 位架构。要注意 x64 这个后缀部分办公电脑还是 32 位系统强行运行 64 位安装包会直接报不是有效的 Win32 应用程序解决办法是回到下载页重新选择 32 位安装包。双击安装包后流程很常规接受协议、选安装目录、下一步即可。有一个容易被忽略的可选项如果本机已装过旧版 Navicat安装向导会询问是否保留旧版的连接配置。建议保留。迁移项目做了一半连接串、SSH 通道、保存的密码都在里面重装后逐条重建连接是纯体力活还容易抄错。首次启动时 Navicat 会做驱动初始化。PostgreSQL 驱动是内置在安装目录里的不需要像 DataGrip 那样手动下载 JDBC jar。如果首次启动后测试连接报driver not initialized优先怀疑安装文件损坏或者杀毒软件隔离了部分 dll。常见处理方式是把 Navicat 安装目录加入杀毒软件白名单然后重装一次。安装完成后主界面左侧是连接树顶部是菜单栏中间是对象面板。新装好的 Navicat 连接树是空的这很正常软件不会自动发现网络里的数据库服务器需要手动创建连接。2.3 新建连接主机、端口、初始数据库与账号密码的填写要点主界面左上角有连接按钮点开下拉列表选择 PostgreSQL。这就是连接人大金仓的关键一步金仓的通信协议兼容 PGNavicat 用 PG 连接器去握手金仓会正常应答。弹出的连接配置窗口里几个字段决定能不能连上第一个是连接名随便写建议按项目-环境-库类型的格式比如迁移验证-测试-金仓。不要只写金仓两个字连接多了根本分不清是哪套环境。第二个是主机填金仓服务器的 IP 或域名。这里有个高频错误是填 localhost除非金仓就装在当前这台电脑上。迁移项目里Navicat 一般跑在个人电脑上金仓在机房服务器或云主机上主机那栏必须填服务器的网络地址。第三个是端口。人大金仓默认端口是 54321这跟 PostgreSQL 的 5432 不一样。不同项目差异很大我遇到过默认 54321、被安全加固改成 54329、还有测试环境沿用 PG 的 5432 这三种情况。端口填错时测试连接会报 connection refused只看这个报错很难定位是端口问题还是服务没启动。连接之前最好先到金仓服务器上确认监听配置# 在人大金仓服务器上查找配置文件并确认端口和监听地址 find /opt /etc -maxdepth 4 -name kingbase.conf 2/dev/null | xargs grep -E ^(port|listen_addresses) 2/dev/null这段命令先在 /opt 和 /etc 目录下最多四层深度查找 kingbase.conf再用 grep 筛选 port 和 listen_addresses 两行。金仓的安装路径不同环境差异很大用 find 兜底比直接 cat 固定路径可靠。输出示例port 54321 listen_addresses *看到端口后照实填进 Navicat。listen_addresses 为 * 表示监听所有网卡地址如果配置的是具体 IPNavicat 主机栏就必须填那个 IP。第四个是初始数据库可以留空但我不建议空。填 postgres 能在连接建立后直接落在系统库上展开连接树能看到所有有权限的数据库列表。留空时 Navicat 会以默认库握手某些权限配置下会有显示差异。第五个是用户名和密码。金仓安装时的超级管理员通常是 system业务账号由项目组分配。密码可以勾选保存密码但我只在个人电脑上勾共享机器上勾了就有明文凭据留在本机这个习惯值得保持。全部填完后点击测试连接Navicat 会发起真实握手并反馈结果。连接配置时的常见问题可以对照下面这张表排查配置项推荐做法典型问题连接名项目-环境-库类型格式命名随意难以辨认主机服务器 IP 或域名误填 localhost端口54321 或确认后的实际值随手填 5432初始数据库postgres留空导致显示不全用户名system 或业务账号权限不足看不到表保存密码个人电脑勾选共享机器存在泄露风险3. 新建数据库与排序规则从源头挡住乱码3.1 新建数据库的操作流与三个关键字段连接建立后右键连接名或某个数据库选择新建数据库弹出的窗口对应 PostgreSQL 的 CREATE DATABASE 语句。核心字段有三个数据库名、编码、排序规则。数据库名建议全小写命名。人大金仓默认把不带引号的标识符折成小写如果你在窗口里输入 UserDBNavicat 生成的是带双引号的名字实际创建的库保留了大小写。后续 SQL 引用时也必须带引号否则报数据库不存在。全小写命名可以完全绕开这套规则。编码字段默认是 UTF8这个通常不用改。有个例外源库如果是 GBK 且业务数据文件量巨大统一转 UTF8 需要额外工作才考虑新建 GBK 库。考虑到 Navicat 转储的 SQL 文件默认带 SET client_encoding UTF8目标库是 UTF8 时导入最省心所以新项目一律建议 UTF8。第三个字段是排序规则和字符分类对应 SQL 里的 collate 和 ctype。这两个参数决定字符串比较、排序、大小写转换的底层规则。金仓里常见选项有 C、zh.CN.UTF-8、zh_CN.UTF-8 等。选错不会立刻报错但会在 ORDER BY、唯一约束、字符串索引这些地方埋雷。建库前建议先在源库查一次基准参数把迁移基准定下来-- 查询指定库的编码、排序规则和字符分类 SELECT datname, pg_encoding_to_char(encoding) AS encoding, datcollate, datctype FROM pg_database WHERE datname 源库名;这条语句从 pg_database 系统目录查库名、编码、排序规则、字符分类。如果结果显示源库的 datcollate 是 zh_CN.UTF-8目标环境又要求排序行为和源库完全一致就把同样的值填到 Navicat 对应下拉框。如果只是建一个内部验证库选 C 更稳妥。原则是先查再建迁移项目最怕拍脑袋定字符集。3.2 排序规则选 C 的底层逻辑与适用边界金仓自带图形工具建库时默认排序规则经常是 zh.CN.UTF-8 这类中文本地化规则。表面看适合中文业务实际用起来往往不可预测。中文字符排序涉及拼音、笔画、unicode 码点多个维度不同操作系统的 locale 数据也不一致。同一段中文在 Windows 上建库和在 Linux 上建库排序结果可能不同。数据迁移后用户立刻会发现列表顺序不对。排序规则选 C 的基本逻辑是绕开操作系统 locale直接按字节二进制序比较字符串。它的优势有三个排序速度快跨平台行为一致结果完全可预测。对于以数据迁移、备份恢复、ETL 为主要诉求的项目C 是风险最低的选项。适用边界也要说清楚C 不解决符合人类习惯的中文排序问题。如果业务库要支撑前端搜索排序、用户明确要求按拼音或笔画排序那就必须用 zh_CN.UTF-8 这类本地化规则。判断标准很简单业务是否依赖字符串的自然语言排序。依赖就选本地化不依赖就选 C。还有一个细节值得注意。金仓集群创建时kingbase.conf 里已有 lc_collate 和 lc_ctype是整个集群的默认语言环境。新建库不指定排序规则时就用集群默认值。在 Navicat 里选排序规则本质上是在覆盖集群默认值。验证当前集群默认值的方法# 在人大金仓服务端查看 locale 相关配置 grep -E ^(lc_collate|lc_ctype|lc_messages) /opt/Kingbase/ES/V8/kingbase.conf输出通常长这样lc_collate C lc_ctype C lc_messages zh_CN.UTF-8前两行是 C说明集群建库时用了 C 排序第三行是消息语言为中文不参与数据比较逻辑。这时在 Navicat 里选 C就能和集群默认一致。如果集群默认是 zh_CN.UTF-8而你强选 C库也能建出来但特殊字符的索引和排序行为会和集群内其他库不一致后续排查问题容易多绕弯路。3.3 乱码的定位顺序与三个典型表现乱码问题九成以上在建库阶段就定了不是连接阶段的展示问题。见到乱码先改客户端字体是我见过最无效的操作。定位顺序应该是先查库编码再查排序规则最后才查客户端连接编码。第一步查库编码。右键库名查看数据库属性或查询 pg_database 视图。UTF8 库配 UTF8 客户端通常不会乱码SQL_ASCII 这类不区分具体编码的库任何非 ASCII 字符都可能写入乱码。第二步查排序规则。排序规则不直接影响字节存储但影响字符串边界判断。某些 locale 下中文字符会被视为等价唯一约束出现明明内容不同却报冲突的情况就是排序规则在捣鬼。这类问题不表现为可见乱码排查起来比乱码更隐蔽。第三步才轮到客户端连接编码。Navicat 连接属性里的编码对应 client_encoding 会话变量。这个值不对会出现一个有意思的现象用 SELECT 查询中文显示正常但从表格编辑器写入的中文变乱码。原因是查询时服务端按客户端编码输出写入时客户端按自己设置的编码发送来回不一致自然乱码。三个典型表现归纳一下库名、表名正常表数据中文变成方框或问号客户端连接编码和库编码不一致。写入中文报错提示某个字节序列无法映射到编码目标库是 GBK 或 SQL_ASCII不接受 UTF8 输入。数据写入成功但中文排序结果和源库不一致排序规则不一致按 3.1 的方式对齐 collate 和 ctype。4. 转储 SQL、复制为插入语句、执行脚本三个高频操作的完整走查4.1 转储 SQL 文件结构与数据分开导出的理由右键库名选择转储 SQL 文件子菜单有仅结构和结构和数据两个选项。很多人图省事直接选结构和数据我建议分开导出。理由有三个。第一结构文件小适合反复改反复执行。结构调整期间可能要在目标库上重建多次表结构只带结构脚本能把排错范围缩小到 DDL 本身。第二数据文件可能非常大几千万行的 INSERT 脚本动辄几个 GB编辑器打不开执行也慢。数据单独导出后可以分批导入或者改用 Navicat 的数据传输功能。第三数据导入出错时不需要重跑结构脚本保留现场更容易定位。转储设置里注意一个选项是否生成 COPY 格式的语句。COPY 格式导入快但语法和 INSERT 差异大在国产化环境里更容易触发解析问题。INSERT 格式兼容性强文件更大、执行更慢。连人大金仓时我一般选纯 INSERT 格式因为目标环境对 COPY 的接受程度在不同版本上有差异INSERT 最保险。转储出的 SQL 文件头部有一段环境设置已生成的典型内容如下-- Navicat 转储文件头部的典型会话设置 SET statement_timeout 0; SET client_encoding UTF8; SET standard_conforming_strings on; SELECT pg_catalog.set_config(search_path, , false);statement_timeout 0 表示取消语句超时限制防止大数据量导入被会话默认超时打断。client_encoding UTF8 声明 SQL 文本编码防止中文字面量在目标库被误解码。standard_conforming_strings on 让反斜杠不再作为转义字符处理字符串字面量更符合标准 SQL。最后一行把 search_path 清空避免对象名解析到非预期模式。如果导入时中文乱码优先怀疑 client_encoding 这一行和目标库编码不匹配。比如目标库是 GBK这句 SET 会把整个会话切到 UTF8INSERT 里的中文字节按 UTF8 解释后再写入 GBK 库结果就是乱码。处理方式是把这一行注释掉或者改成目标库的编码。4.2 复制为插入语句小批量搬运和造数复制为插入语句功能在数据表的右键菜单里。选中数据网格若干行右键选复制为再选复制为插入语句Navicat 就把选中行拼成 INSERT 语句放进剪贴板。用途集中在三类小批量数据搬移、造数、SQL 脚本片段复用。这个功能不适合大数据量。复制操作在客户端内存里拼字符串几万行就明显卡顿几十万行可能直接无响应。我一般限定在几千行以内超过五千行就改用转储或数据传输。复制出来的 INSERT 语句有个特点必须注意表名和列名默认带双引号且保留原始大小写。在金仓这种兼容 PG 方言的库里双引号内的名字是大小写敏感的。如果表创建时用的不带引号的小写名复制出来的语句却带双引号执行会报 relation 不存在。整套规则新手容易绕晕。我的处理方式分两步走-- 第一步确认实际表名注意大小写 SELECT table_name, table_schema FROM information_schema.tables WHERE table_schema public ORDER BY table_name; -- 第二步在 Navicat 编辑器里用 CtrlH 把 INSERT 语句中的双引号去掉表名为小写时第一步查出表名真实大小写。第二步用编辑器自带查找替换去掉双引号。如果表名全小写且下划线分隔去掉双引号后金仓会折叠为小写恰好匹配。如果表名真是混合大小写建的就不要去掉双引号保持原样执行。复制为插入语句还有一个额外价值造数。我先从生产金仓库复制几条真实复杂数据回贴到测试库改掉唯一键字段再插入。真实数据比手工构造的数据更能暴露字段长度和类型边界问题比如某字段长度被压到边界值手工造数根本想不到这个场景。4.3 执行 SQL 语句从编辑器到结果集的完整流程查询编辑器是日常使用率最高的界面。打开方式有两种工具栏新建查询按钮或右键库名选新建查询。后者把库直接绑定到查询窗口窗口标题会带库名多个查询窗口同时开着也不容易混。编辑器支持多条语句一次性执行。点运行按钮后Navicat 把当前选中的内容或整个窗口内容发给服务器执行。结果在下方网格显示多个结果集以标签页切换。多语句执行时Navicat 默认遇到第一条报错就停这对排查单个问题友好但对批量初始化脚本不友好。需要跳过部分报错继续执行时去连接属性 - 高级里把执行策略改成继续执行。执行之前先做一次自检比较稳妥-- 检查两张核心业务表的行数确认连接和数据可见性 SELECT sys_user AS tbl_name, count(*) AS row_cnt FROM sys_user UNION ALL SELECT sys_order, count(*) FROM sys_order;这条 SQL 用 UNION ALL 把两张表的行数查询合并成一个结果集。输出两行分别是表名和行数。它能一次性验证三件事连接权限正常、表真实存在、数据量级符合预期。如果某张表没有权限查询会在那一行报错并精确指到表名而不是笼统提示无权限。执行完看结果不要只盯错误。查询语句结果集行数异常时把 SQL 拆半定位加 WHERE 条件逐步缩小范围。非查询语句只显示受影响行数如果为 0检查 WHERE 是不是没匹配到任何数据。我还有一个习惯把执行过的核查 SQL 保存到 Navicat 左侧查询树里。查询文件只是本地 SQL 文件引用双击就能打开执行省去重复编写。迁移项目里积累的那套核查脚本换一个连接后直接复用效率提升明显。5. 连接人大金仓的常见问题排查五条真实踩坑记录5.1 测试连接报错connection refused 或 driver not initialized现象点击测试连接后报错内容包含 connection refused偶尔是 driver not initialized。原因connection refused 表示网络能到目标主机但目标端口没服务响应通常是端口填错或服务没启动。driver not initialized 说明 Navicat 的内置驱动加载失败常见原因是安装路径含中文或杀毒软件隔离了部分文件。解决先到金仓服务器上确认端口用 2.3 里的 find 加 grep 命令查 kingbase.conf再用 telnet 目标 IP 端口测试连通性。端口通就检查账号密码和初始数据库配置。驱动问题直接重装 Navicat安装路径改为纯英文并把安装目录加入杀毒软件信任区。5.2 连接成功但看不到业务表现象连接树能展开数据库节点只显示系统模式业务表一张都看不到。原因当前账号缺少对应模式或表的使用权限。金仓默认在 public 模式下建业务表账号如果没有 usage 权限Navicat 的元数据查询拿不到表列表界面自然空白。解决用 system 账号执行授权把 usage 和 select 权限授予业务账号。同时确认表是否都在 public 模式如果业务表在 app 模式等其他 schema 下就在连接配置里指定默认模式或单独授权给该模式。5.3 中文乱码或含中文的 INSERT 报错现象查询结果显示乱码或者执行带中文的 INSERT 语句报错提示某个字节序列无法映射到目标编码。原因库编码和客户端连接编码不一致。常见组合是库编码 GBK连接编码 UTF8写入中文时服务端无法把 UTF8 字节转成 GBK。库是 SQL_ASCII 时更麻烦本身不记录编码写进去就乱。解决在连接属性里把编码改成与目标库一致。新库推荐删除重建为 UTF8不要在错误编码的库上继续开发后面补的坑比重建成本高得多。5.4 转储的 SQL 文件在目标库执行时语法报错现象从 PostgreSQL 源库转储的 SQL 文件在金仓目标库执行时报语法错误常见是 COPY 语法不识别或某个函数不存在。原因金仓的 SQL parser 没有完整覆盖 PostgreSQL 的扩展语法尤其是 COPY 批量格式、部分类型转换函数、分区表语法。Navicat 转储时按 PostgreSQL 方言生成不会自动翻译成金仓方言。解决导出时选纯 INSERT 格式绕开 COPY 语法。导入报错后定位到具体语句手动改写为金仓支持的写法。批量处理时先把文件头部多余的 SET 语句整段注释降低 parser 负担。5.5 复制为插入语句后目标库报表不存在现象Navicat 生成的 INSERT 语句执行时报错 content 是 relation xxx does not exist。原因Navicat 生成的插入语句把表名和列名用双引号包裹并保留原始大小写。建表时用的无引号小写名内部存储是小写插入语句里的双引号名称匹配不上自然找不到表。解决在编辑器里用查找替换去掉双引号前提是确认表名是纯小写。如果表名确实是混合大小写建的需要保留双引号并逐一核对。执行前先用 4.3 的 information_schema 查询确认实际表名。6. 连接后的自检清单三个顺手技巧连接成功不是终点。每次用 Navicat 连接人大金仓库之后我会按一套自检清单过一遍确认库配置没问题再往里灌数据。检查项方法期望结果编码一致性SELECT pg_encoding_to_char(encoding) FROM pg_database WHERE datname 库名UTF8 或与源库一致排序规则SELECT datcollate, datctype FROM pg_database WHERE datname 库名与源库一致或为 C业务表数量查询 information_schema.tables 中非系统模式的表数与源库数量一致数据抽查复制两三个核心表的插入语句做对比字符和数字无乱码技巧一是把常用查询存成查询文件。自检 SQL、数据量核查 SQL、权限检查 SQL全部保存在 Navicat 左侧查询树里。下次连接任意一个库双击就能再次执行。查询文件绑定的连接变了右键更换连接名即可SQL 本身不用重写。技巧二是用数据传输功能做结构对比。建库完成、数据导入之前用 Navicat 的数据传输选择两个连接勾选表结构对比几分钟就能看出哪张表少了字段、哪个字段类型不匹配。这个动作我每次迁移前必做能省掉后续大量 SQL 报错排查。技巧三是用逆向数据库生成 ER 图。接手一个没有设计文档的金仓库时右键数据库选择逆向数据库Navicat 会扫描表、视图、外键关系生成 ER 图。之前接手的某个老库十来张表没有任何文档全靠这个功能理清了表关系。早年间我在一个迁移项目里把排序规则设错了还不自知直到用户反馈列表顺序混乱才回去查整整耗掉一个下午。从那以后每次连上人大金仓的第一件事就是查库的 datcollate 和 datctype写入自检清单强制走一遍翻车的概率明显降下来了。希望帮到你。本文还有配套的精品资源点击获取