企业官网建设流程全解析

简介：《使用Navicat连接人大金仓》是一份面向数据库开发、运维及迁移实施人员的实操型文档，重点解决通过Navicat图形化工具连接和管理人大金仓数据库时，连接配置、库表操作与数据迁移中的常见问题。压缩包内共1个docx文件，大小约1.62MB，内容按Navicat介绍、下载安装、创建连接、账号密码配置、连接成功后的操作、创建数据库、转储SQL文件、复制为插入语句及执行SQL语句等模块组织，并补充排序规则与字符集设置等注意事项，可帮助读者减少乱码和连接失败等排错成本。文档还说明使用C字符集以保持迁移库一致，兼顾日常查询、备份导出与快速迁移场景。目前已有1302人学习，适合需要快速上手Navicat连接人大金仓或查漏补缺的初、中级数据库从业人员参考。

1. 从一次「连不上」说起：Navicat 连人大金仓到底走的是哪条协议

同事把 Navicat 的连接配置截图发过来，主机、端口、账号、密码一项不差，点「测试连接」却弹出一行英文报错，他坚称「参数是照文档抄的」。这种场面在数据库替换的项目里几乎每周都碰得到。用 Navicat 连接人大金仓（KingbaseES），难的不是填那几个框，而是要先把一件事想明白：Navicat 的连接类型列表里根本没有「人大金仓」这一项，它走的是 PostgreSQL 那个入口，默认端口也不是 5432 而是 54321。这篇按我自己的操作顺序拆：装包、建连接、建库躲开乱码、转储 SQL、复制为插入语句、执行调试，每一步给出可直接抄的参数，以及失败时该按什么顺序回查。适合刚接手国产库迁移、手上只有 Navicat 没有专用客户端的人。

2. 选对入口比装对版本更重要：Navicat 与人大金仓的协议层关系

动手之前先把「为什么能连」这件事讲清楚，否则后面每一次报错你都会怀疑是不是选错了连接类型。Navicat 支持 MySQL、Oracle、PostgreSQL、SQLite、SQL Server、MariaDB、MongoDB 等一长串数据库，人大金仓不在这个名单里，但它在内核层兼容 PostgreSQL 的前后端通信协议，也就是说，一个按 PostgreSQL 协议发出去的握手包、认证包、查询包，人大金仓的服务端是认的。Navicat 的 PostgreSQL 驱动干的就是这件事，它不知道对面站的是谁，只负责把协议包发过去、把结果集解析回来。所以「用 Navicat 连接人大金仓」在技术上等价于「用 PostgreSQL 客户端连一个改了默认端口的 PostgreSQL 兼容库」。

理解这一层之后，很多现象就顺了：Navicat 里能用的 SQL 编辑器、表设计器、数据传输、结构同步大部分都能正常工作，因为它们走的都是标准协议和标准系统表；而一旦某个功能依赖 PostgreSQL 特有的扩展视图或者版本号判断，就可能翻车。我一般会把这类功能当成「能用是赚到，不能用是正常」，不把它写进交付流程里。

2.1 安装包与版本的取舍边界

原文给出的下载地址是官方下载页，安装包文件名形如navicat161_premium_cs_x64.exe，premium表示 Premium 版，cs是简体中文界面，x64是 64 位。这三个后缀不是装饰：Premium 版才是把多种数据库连接类型打通的版本，如果你装的是功能精简的版本，连接类型下拉框里可能压根找不到 PostgreSQL 这一项，后面所有步骤都无从谈起。

安装过程没什么可讲的，双击、下一步、选路径。我给两个实操建议。第一，安装路径别带中文和空格，某些老版本的驱动加载对路径敏感，出问题时报错信息完全指不到根因，属于典型的玄学故障。第二，装完之后先别急着点「检查更新」升到最新，新版本客户端在连接属性里对 SSL 的默认策略可能更严格，而测试环境的人大金仓服务端往往没配证书，握手阶段就会卡住。真遇到这种情况，不用降版本，去连接属性的 SSL 页签把它改成「不使用」即可。

2.2 连接类型必须选 PostgreSQL 的原因

打开 Navicat，左上角「连接」→「新建连接」，弹出的菜单里是一排数据库图标。选 PostgreSQL，不要去找所谓的「其他」或者「通用 ODBC」。走 ODBC 也能连上，但你会失去 Navicat 对 PostgreSQL 协议的原生支持，表设计器、数据传输这些依赖元数据接口的功能会退化，得不偿失。

选定 PostgreSQL 之后，Navicat 会预填一组默认值：主机localhost、端口5432、初始数据库postgres、用户名postgres。这五个默认值里，对人大金仓来说至少有三个是错的：端口通常是54321，初始库通常不是postgres，默认管理账号通常也不是postgres。新手最容易在这里栽跟头——看到「测试连接」失败就回头怀疑密码，其实端口那一栏还停在 5432。

2.3 连接前必须先确认的四个初始值

与其在 Navicat 里瞎试，不如先在服务端把这四个值确认下来。这四个值确认完，Navicat 那边就是填空题，一次就能过。

确认端口这一项有个坑：kingbase.conf里如果port那一行被注释掉了，实际生效的可能是编译时的默认值，不同发行包不一定一致。最可靠的办法是在服务端用ksql连上去执行SHOW port;，它返回什么就是什么，别猜。

# 在数据库服务器本机上执行，确认端口、监听地址和版本 ksql -U system -d test -c "SHOW port;" ksql -U system -d test -c "SHOW listen_addresses;" ksql -U system -d test -c "SELECT version();"

第一条返回实际监听端口，跟 Navicat 里填的必须一致；第二条返回监听地址，如果是localhost而你从别的机器连，那必然连不上，得改配置重启；第三条返回版本串，形如KingbaseES V008R006...，记下这个号，后面挑驱动、判断兼容模式都用得上。参数说明就一句：-U是数据库用户，-d是库名，-c是「执行完这条就退出」，不做交互。这三条命令能跑通，说明服务端本身是健康的，后面 Navicat 再连不上就是网络或者客户端配置的问题，排查范围直接砍掉一半。

3. 建立连接并跑通第一条 SQL：54321 端口背后的五层排查

连接建不起来的时候，绝大多数人的第一反应是「密码错了」，然后一遍遍重输。实际上从客户端到服务端要穿过五道关：网络可达、端口开放、服务端监听、认证规则放行、账号密码正确。这五道关任何一道没过，报错信息都长得差不多，只有逐层排除才不浪费时间。这一章按「先填、再测、再交叉验证」的顺序走。

3.1 新建连接的具体填写顺序

在 Navicat 里点「连接」→「PostgreSQL」，弹出对话框，从上往下填：

1. 连接名：随便写，但要能自解释，比如kingbase-test-54321。连接名不影响连接，只影响你以后在左侧列表里认不认得出它。
2. 主机：填服务器 IP。同机部署才填localhost，容器里跑的话注意端口映射。
3. 端口：改成54321。
4. 初始数据库：填test或者你要操作的业务库。
5. 用户名 / 密码：system加初始化密码。

填完先别急着点「测试连接」，去「高级」或者「SSL」页签看一眼 SSL 设置，改成不使用。然后回到主界面点「测试连接」。

-- 连接成功后，在查询窗口里跑这三条，确认对面确实是人大金仓而不是原生 PG SELECT version(); SHOW server_encoding; SHOW client_encoding;

这三条是「验明正身」用的。version()的返回值里带KingbaseES字样，能一眼区分；server_encoding告诉你库的字符集，client_encoding告诉你当前会话的字符集，这两个值不一致就是后面中文乱码的种子。参数说明：SHOW是会话级参数查询，不需要权限，任何账号都能跑；SELECT version()返回的是服务端编译信息，不受权限限制。

3.2 测试连接失败的四种报错与对应动作

报错信息虽然都带英文，但关键词能区分关卡，按关键词对号入座就行。

关键词「Connection refused」或「could not connect」：网络层就没通。先ping主机，再用telnet 主机 54321或者nc -zv 主机 54321探端口。端口不通说明要么服务没起，要么防火墙挡了，要么服务端只监听了本地回环。

关键词「timeout」：包发出去了但没有回应，典型是防火墙丢包或者中间有安全设备拦截。这种情况下telnet会一直挂着不返回，能卡十几秒。

关键词「password authentication failed」：走到认证关了，说明网络、端口、监听都没问题，纯粹是账号密码或者认证规则的事。先去服务端确认密码，再去看认证规则文件。

关键词「database does not exist」：认证过了，但库名填错了。用ksql -l列出所有库对一遍。

服务端这边要看的配置文件一共三份，都在数据目录下：

sys_hba.conf这一份是新手最容易忽略的。默认配置里通常只写了127.0.0.1/32的本地回环放行，你从另一台机器连，来源地址对不上任何一条规则，服务端就直接拒绝，报错还长得像密码错误。加一条host all all 0.0.0.0/0 md5然后重载配置就能解决，但注意：这样等于对全网段放开，生产环境务必把0.0.0.0/0收窄到具体网段，别图省事。

改完配置需要重载，不是重启：

# 重载认证配置与主配置，不中断现有连接 ksql -U system -d test -c "SELECT sys_reload_conf();"

sys_reload_conf()是人大金仓提供的重载函数，效果等同于给服务端发 SIGHUP。有一点要记住：listen_addresses和port这两项改完，重载是不生效的，必须重启服务。认证规则文件改完重载即可。这个区别我吃过亏，改完监听地址只重载，怎么试都不通，最后发现得重启。

3.3 用 ksql 交叉验证，把问题关在 Navicat 之外

排查最忌讳的就是只在一个客户端上反复试。正确姿势是在服务器本机用命令行客户端连一次，把「服务端问题」和「客户端问题」彻底切开。

# 第一步：本机回环连，验证服务本身 ksql -h 127.0.0.1 -p 54321 -U system -d test -c "SELECT 1;" # 第二步：用真实 IP 连，验证监听地址 ksql -h 10.0.0.21 -p 54321 -U system -d test -c "SELECT 1;"

第一条通了、第二条不通，问题百分之百在listen_addresses或者认证规则；两条都通，问题就在 Navicat 那侧的参数或者客户端机器的网络；两条都不通，服务压根没起来或者端口不对。这三行命令能省掉大量猜测。

如果服务器上没有ksql命令，说明客户端工具没装或者不在 PATH 里，找Kingbase/ES/V8/Server/bin这个目录，一般在安装目录下。提示：这个命令行工具的用法与psql基本一致，\l列库、\dt列表、\q退出，熟手可以直接上手。

3.4 连上之后：对象树里能看到什么、看不到什么

连接成功后，左侧会展开一棵对象树：库 → 模式（schema）→ 表、视图、函数。这里有个认知差异要提前建立：人大金仓在 PostgreSQL 兼容模式下，默认模式叫public；如果初始化时选了 Oracle 兼容模式，每个用户会有一个与用户名同名的模式，比如system用户下的对象就在system模式里，不在public。

这就是很多人「连上了但看不到表」的原因——表在system模式下，Navicat 只展开了public。解决办法是在连接属性里勾选「显示所有模式」，或者直接在对象树里手动展开对应模式。

另一个常见现象是 Navicat 的对象树加载特别慢，转圈转半分钟。这不是连接有问题，是 Navicat 在后台查询系统表拉全量对象信息，库里的表和模式一多就会慢。我的做法是给连接加一个「数据库」过滤，只显示我关心的那几个库，或者干脆在连接属性里关掉「自动加载对象」。

-- 确认当前库下有哪些模式，以及表都落在哪个模式 SELECT schema_name FROM information_schema.schemata ORDER BY 1; -- 确认某个模式下的表数量，判断对象树慢是不是因为对象太多 SELECT table_schema, count(*) AS tbl_cnt FROM information_schema.tables GROUP BY table_schema ORDER BY tbl_cnt DESC;

第一条列出全部模式，你就能对上 Navicat 树里为什么多出来一个system；第二条按模式统计表数量，如果某个模式有几万张表，那对象树慢就是必然的，跟网络和驱动都没关系，只能通过过滤来缓解。information_schema是标准视图，在人大金仓里可用，但查全量对象的性能不如直接查pg_catalog，量大时注意别在业务高峰期跑。

4. 建库这一步最容易翻车：字符集、排序规则与兼容模式

连接是入口，建库是地基。地基歪了，后面迁移数据、转储 SQL、跨库比对全都会跟着歪。原文里有一句提醒说得很到位：「排序规则和字符分类在迁移库要一致，否则会出现乱码，建议使用 C」。这句话方向对，但把两件事揉在一起了，需要拆开讲清楚，否则你会以为改了 collate 就能解决乱码，结果白折腾。

4.1 新建数据库对话框里每个字段在数据库里对应什么

在 Navicat 里右键连接名或者库，选「新建数据库」，弹出的对话框有几个字段。这些字段不是 Navicat 自己编的，每一个都对应服务端的一条建库参数。

这五个字段里，真正决定「中文会不会乱码」的是编码，不是排序规则。排序规则影响的是ORDER BY时中文按什么顺序排、BETWEEN的范围判定、唯一索引判重时的比较方式，它不改变字节的存储形式。把这两个概念分开，后面所有的判断都会清晰。

4.2 C 与 zh_CN.UTF-8：乱码和排序是两件事

先给结论：中文乱码的根因是「编码不一致」，不是「排序规则不一致」。具体来说，是数据写入时的客户端编码、数据库编码、以及转储/导入时的会话编码三者之间不匹配。

设想一条链路：源库编码是 UTF8，你从一台 Windows 客户端用 GBK 会话连上去查，客户端把 GBK 字节发过去，服务端按 UTF8 解释，存进去的就是一堆乱码；反过来，源库编码是 GBK，你用 UTF8 会话去导数据，同样变形。这种问题在 Navicat 里表现为表里的中文变成问号或者方块，而在命令行里可能完全正常——因为两边会话的client_encoding不同。

排序规则C又是另一回事。C的含义是「按字节序比较」，它带来的好处是：比较速度快、索引紧凑、跨平台行为完全一致，不会因为操作系统 locale 差异导致同一批数据在两台机器上排序结果不同。代价是中文不按拼音排序，ORDER BY 姓名出来的顺序是编码顺序，不是新华字典顺序。

所以原文那句「建议使用 C」的适用场景是：你要的是一个行为稳定、可预测、不会因为环境差异而变的库，中文排序顺序不重要。如果业务上明确要求中文按拼音排序，那就得用zh_CN.UTF-8这类 locale，但要接受它依赖操作系统的 locale 支持，跨平台迁移时可能出岔子。

我的默认选择是：编码统一 UTF8，排序规则用 C，字符分类也用 C。理由是迁移场景里最怕的是「同一份数据在两边表现不一致」，C把变量降到最低。中文排序的需求在应用层用ORDER BY convert_to(字段, 'GBK')或者应用侧排序解决，比在数据库层面引入 locale 依赖更可控。

-- 推荐建库语句：纯 UTF8 存储 + C 排序，行为可预测 CREATE DATABASE appdb WITH ENCODING = 'UTF8' LC_COLLATE = 'C' LC_CTYPE = 'C' TEMPLATE = template0;

逐项说明：ENCODING='UTF8'保证中文、日文、emoji 都能存；LC_COLLATE='C'让排序和索引比较走字节序，性能好且跨平台一致；LC_CTYPE='C'让大小写转换只认 ASCII，中文不受影响；TEMPLATE=template0是关键——template1可能已经被别人改过编码或者装过扩展，用template0才能保证新建的库是干净初始状态，而且指定与模板不同的编码时必须用template0，否则报错「new encoding is incompatible with the template database」。这一条不写，上面那串参数一半会报错。

4.3 建完库用 SQL 复核，别信界面显示

Navicat 的建库对话框有个毛病：你选了编码和排序规则，它不一定老老实实传下去，尤其是通过图形界面建库时，某些版本会忽略排序规则字段，用服务端默认值。稳妥做法是建完立刻用 SQL 复核。

-- 复核当前库的编码与排序规则 SELECT datname, pg_encoding_to_char(encoding) AS encoding, datcollate, datctype FROM pg_database WHERE datname = current_database(); -- 顺便看一眼兼容模式相关参数的取值 SELECT name, setting FROM pg_settings WHERE name LIKE '%mode%' ORDER BY name;

第一条返回四列：库名、编码、排序规则、字符分类。你期望看到的是UTF8、C、C。如果datcollate显示的是zh_CN.UTF-8或者en_US.UTF-8，说明对话框里的排序规则没生效，要么重建库，要么就接受这个设定但心里有数。第二条查兼容模式相关参数，人大金仓初始化时可以选 Oracle 兼容或 PostgreSQL 兼容，不同小版本参数名可能不一样，用模糊匹配一次性捞出来看比死记硬背强。

注意：编码在建库后不能改。发现建错了，唯一办法是导出数据、删库、用正确参数重建、再导入。这个代价很大，所以建库这一步宁可多花两分钟复核，别指望事后补救。

4.4 兼容模式带来的大小写陷阱

如果这个库是在 Oracle 兼容模式下初始化的，会碰到一个让新手抓狂的现象：建表时写CREATE TABLE User_Info，之后查询必须写SELECT * FROM "User_Info"带双引号，不带引号就报「表不存在」。

原因是 Oracle 兼容模式下，未加引号的标识符会被统一折叠成大写（或者按 Oracle 的习惯处理），而你建表时如果用双引号包了混合大小写，它就原样存下来。两者一混，就找不到对象。

-- 在 Oracle 兼容模式下，这几条的行为完全不同 CREATE TABLE t_lower (id int); -- 折叠成 T_LOWER 还是 t_lower，取决于模式 CREATE TABLE "t_mixed" (id int); -- 双引号锁定大小写，原样存储 SELECT * FROM t_mixed; -- 未加引号，可能找不到 SELECT * FROM "t_mixed"; -- 加引号，一定能找到

我的习惯是：迁移场景里表名、字段名一律用小写，一律不加双引号，让数据库自己折叠。这样不管服务端是哪种兼容模式，生成的标识符至少在同一个库里是自洽的。真正要命的是跨库迁移——从 Oracle 兼容模式导到 PostgreSQL 兼容模式，大写表名带双引号的 DDL 到对面就变成「必须带引号」，而应用代码里没带引号，一上线就报错。这类问题在转储 SQL 之前就该定好规则。

5. 避坑清单：连接、乱码、转储的五个高频翻车现场

下面这五条是我在不同项目里真实遇到过的，按「现象 → 原因 → 解决」记录，遇到相似症状直接对号入座，别从头猜。

5.1 测试连接报 Connection refused，但服务明明在跑

现象：服务器上ksql能连，Navicat 从自己电脑连报Connection refused，telnet端口也不通。

原因：kingbase.conf里listen_addresses只写了localhost或者127.0.0.1，服务端只在回环网卡上监听，外部 IP 根本没有 socket 在听。这种情况ksql -h 127.0.0.1一定通，ksql -h 真实IP一定不通。

解决：把listen_addresses改成'*'或者具体网卡 IP，重启服务（这一项重载不生效），再放行防火墙端口。改完先用ksql -h 真实IP验证，通了再去配 Navicat。

5.2 认证失败，密码确认是对的

现象：password authentication failed for user "system"，但用命令行同一套账号密码能进。

原因：sys_hba.conf里针对不同来源地址配了不同的认证方式。本机回环那条规则可能是trust（免密），所以命令行「看起来」密码是对的；你从远端连走的是另一条规则，认证方式不同，密码校验就失败了。另一种可能是密码加密算法不匹配，比如服务端用scram-sha-256，老客户端只支持md5。

解决：先看sys_hba.conf里来源地址匹配到哪一条规则；再看认证方式与服务端密码存储格式是否匹配。改完执行SELECT sys_reload_conf();重载。提示：排查期间别在生产上改成trust图省事，改完记得改回来。

5.3 中文变问号，英文正常

现象：表能查，数据能看，但中文全是???或者方块，英文和数字完好。

原因：会话编码与服务端编码不一致。最常见的是客户端client_encoding停留在某个单字节编码，而库是 UTF8；也可能是建库时编码选成了SQL_ASCII，那个编码不做任何校验，什么字节都往里塞，读出来就靠运气。

解决：先跑SHOW server_encoding;和SHOW client_encoding;对比。如果是会话级不一致，在 Navicat 连接属性的「编码」里指定 UTF8；如果是库级编码错了，只能导出重建。注意：SQL_ASCII建出来的库，事后改编码改不了，只能重建，这是建库那一刻就决定的。

5.4 转储的 SQL 在目标库执行报语法错

现象：从 A 库转储出 SQL 文件，拿到 B 库执行，报syntax error at or near "number"或者类型不存在的错。

原因：A 库是 Oracle 兼容模式，表里用了NUMBER、VARCHAR2、DATE这类 Oracle 风格类型；B 库是 PostgreSQL 兼容模式，不认这些类型。反过来也一样，text、serial搬到 Oracle 兼容模式下可能出问题。

解决：转储前先确认源库和目标库的兼容模式，跨模式迁移时手工改写 DDL 里的类型映射：NUMBER→numeric，VARCHAR2(n)→varchar(n)，DATE在 Oracle 里带时分秒、在 PostgreSQL 里纯日期，得按语义改成timestamp。这个活没有自动化工具能百分百代劳，转储前手工过一遍 DDL 是最省时间的。

5.5 对象树转半天出不来，或者打开表卡死

现象：连接是通的，SELECT 1秒回，但左侧对象树一直在转圈，或者双击某张表卡住几十秒。

原因：对象树加载时 Navicat 会查一批系统视图拉元数据，库里的表、视图、函数数量一多，加上统计信息过期，查询就会变慢。另外，如果连的是只读账号，Navicat 某些需要探测权限的查询会超时等待。

解决：在连接属性里关掉「自动加载对象」或者限定只显示指定库；表多的情况下先在 SQL 窗口用information_schema定位表名，再针对性打开，不要靠对象树浏览。统计信息过期的话，让 DBA 跑一次ANALYZE也能缓解。

6. 转储与复制插入的回放校验：让搬过去的数据自己证明没丢

数据搬完，最危险的不是报错，是「没报错但少了东西」。转储 SQL 文件这个功能，Navicat 给的选项不少，默认值不一定适合迁移场景。我的习惯是转储前把三个选项确认一遍：勾上「包含建表语句」否则目标库没表可插；勾上「包含数据」；把「遇到错误继续」关掉——迁移要的是「要么全成功要么立刻停」，让它带错继续跑，跑到最后你根本不知道丢了多少行。

还有一个选项叫「使用事务」，开了之后整个转储文件会被包在BEGIN/COMMIT里，回放时要么全进要么全不进，比逐条插入安全得多。文件体积会大一些，但换来的可回滚性值得。

# 回放转储文件，并把输出重定向到日志，事后可查错在哪一行 ksql -h 10.0.0.21 -p 54321 -U system -d appdb \ -v ON_ERROR_STOP=1 \ -f /data/dump/appdb_2024.sql > /data/dump/replay.log 2>&1

-v ON_ERROR_STOP=1是关键参数，遇到第一个错误就停，不让错误雪崩；-f指定脚本文件；重定向把标准输出和标准错误都留在日志里，出问题时能定位到具体语句。注意：如果用 Navicat 的「运行 SQL 文件」功能回放，它默认是不中断的，几万行里错几十条也能跑完，看起来成功，实际数据是残缺的。

至于「复制为插入语句」，它适合小批量、点对点的数据搬移，比如把十几行配置表搬到另一套环境。用的时候留意两点：一是bytea、json这类二进制或结构化字段，复制出来的字面量可能带转义，粘过去执行会变形；二是timestamp with time zone会带上原始时区偏移，目标库时区设置不同，落库值就变了。批量超过几百行，就别用复制插入，老老实实转储。

回放完做三个校验动作，缺一不可：比对源库和目标库的行数、比对关键表的max(主键)、抽三行中文数据人工看一眼有没有乱码。行数对上、主键连续、中文正常，这三条过了才算搬干净。

-- 一次性把所有业务表的行数拉出来，方便两边对照 SELECT schemaname, relname, n_live_tup FROM pg_stat_user_tables ORDER BY relname;

pg_stat_user_tables里的n_live_tup是统计信息估算值，不是精确值，用来做「量级对不对」的快速判断足够，但正式验收还是得对关键表跑count(*)。这个区别要分清，否则可能因为估算偏差误判成数据丢失，白折腾一轮。

血泪经验是：转储前先在源库跑一遍统计，转储后在目标库跑同一份统计，两份结果并排贴在一起看，比事后逐表查快得多。从那以后我每次做库迁移，都会先把这份行数快照存成文件，回放完第一件事就是拿它对照——数据不会说谎，但会沉默，你得主动去问它。希望帮到你。

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