简介一份面向数据库管理初学者的图文操作指南围绕使用Navicat连接国产人大金仓数据库的完整流程展开系统讲解从工具下载安装、创建连接、配置账号密码到新建数据库、转储SQL文件、复制插入语句及执行SQL语句等核心操作。文档同时针对字符集和排序规则给出明确建议可帮助读者规避乱码问题并理解连接配置中的关键细节。包体为单个docx文档大小约1.62MB内容结构清晰、步骤一目了然适合需要快速上手Navicat与人大金仓协同工作的运维工程师、数据处理人员或数据库初学者。该资源已有1279人学习下载除了完整的操作步骤说明还包含使用官方工具与Navicat的对比提示、权限与安全注意事项等实用经验便于读者在实际项目中灵活选用连接方式提升国产数据库的管理效率。1. Navicat 连人大金仓为什么值得搭这一条连接很多第一次接触人大金仓的同事习惯直接用 KingbaseES 自带的图形工具觉得官方工具总不会错。但我自己连着做了两个迁移项目之后反而更推荐用 Navicat 去连金仓——不是因为官方工具不好而是因为金仓兼容 PostgreSQL 协议Navicat 对 PG 生态的连接、排查和 SQL 编写支持都足够成熟界面也比自带工具更顺手。这条连接打通之后日常建库、导数据、调试 SQL 都能在一套工具里完成不用在几个客户端之间来回切换。这篇文章面向的是实施工程师、DBA 和数据迁移人员把从下载安装、建连接、建库到转储 SQL 的完整链路过一遍并把我踩过的排序规则、权限、端口这些坑一并说清楚。2. 装好 Navicat 并建第一个连接端口、驱动和账号是三个关键点2.1 下载安装官网拿安装包注意版本位数Navicat 的下载可以直接走官网Windows 环境下选择 Navicat Premium 的 x64 安装包例如navicat161_premium_cs_x64.exe。下载时注意两点第一操作系统是 32 位还是 64 位现在金仓服务端基本都在 x64 环境客户端也建议直接用 x64 版本避免装出 32 位后在大表操作时内存受限第二Navicat Premium 是 All-in-One 的客户端支持 MySQL、PostgreSQL、Oracle、SQL Server 等连人大金仓时我们走的是 PostgreSQL 通道所以不需要额外装金仓专用版。安装过程没有特别要说的一路下一步即可。需要注意安装路径不要放在带中文的目录下Navicat 在某些中文路径场景下会出现莫名其妙的加载异常虽然不常见但没必要去赌这个概率。2.2 连接前先确认三件事端口、驱动、账号在打开 Navicat 创建连接之前我建议先确认三个信息避免连不上时来回猜确认项常见值说明服务器 IP测试环境或生产环境的 IP金仓和客户端能互通是前提端口54321人大金仓默认端口是 54321不是 PostgreSQL 的 5432这点非常容易踩坑账号/密码由 DBA 分配的账号金仓默认有 SYSTEM 账号但实际项目一般会单独建业务账号确认端口时可以直接在客户端机器上敲一下telnet 192.168.1.100 54321如果端口不通先看防火墙和安全组如果通了会出现连接成功的空窗口说明网络层面没问题。我一般会在这一步多做一件事用ping确认 IP 能通再用telnet确认端口能通两个都过了再开 Navicat排错范围会小很多。2.3 创建连接选对连接类型填入连接信息打开 Navicat点击左上角「连接」下拉列表里没有写人大金仓的选项但我们不需要选MongoDB或MySQL而是选PostgreSQL。理由是人大金仓 KingbaseES 的对外协议兼容 PostgreSQLNavicat 的 PostgreSQL 驱动可以完成握手。连接窗口里需要填这几项连接名自己能识别的名字比如金仓-UAT主机金仓服务器的 IP 或域名端口默认 54321初始数据库可以先填test或者template1如果不知道有哪些库就留空用户名和密码DBA 分配的账号填完之后可以先不点「确定」点一下「测试连接」。如果弹窗提示连接成功说明底层通了如果弹的是认证失败优先检查密码其次查服务端的认证配置。这里有一个细节Navicat 在连接 PostgreSQL 协议时高级选项卡里有一项「编码」建议直接选UTF-8。金仓的字符集默认就是 UTF-8客户端编码不一致是后面乱码最常见的源头。连接保存后左侧列表会出现这个连接实例展开之后能看到数据库列表、表、视图这些对象。到这里Navicat 连金仓这条链路已经打通了。3. 创建数据库排序规则不一致乱码会跟你到迁移完成3.1 新建数据库时看到的三个下拉框分别管什么连接建好之后右键连接实例选择「新建数据库」会看到名称、所有者、字符集、排序规则、字符分类这几个字段。很多人在这里直接点「确定」等到迁移数据时才发现问题那时候再改库的编码和排序规则就非常被动了。Navicat 新建 PostgreSQL 类型数据库时关键的三个选项是选项作用建议字符集决定数据库用什么编码存数据UTF8金仓和 Navicat 默认都认这个排序规则决定 ORDER BY、索引排序用哪套规则建议 C理由见下文字符分类决定字符比较和分类逻辑和排序规则保持一致如果你看到的选项名是LC_COLLATE和LC_CTYPE也不用慌金仓兼容 PostgreSQL这两个参数本质上就是排序规则和字符分类的底层实现。Navicat 的图形界面把翻译和原生参数混合在一起有时候字段名会随版本变化但逻辑是一致的。3.2 C 和 zh.CN.UTF-8 到底差在哪这是我在金仓迁移项目里被问得最多的问题也是最容易翻车的位置。人大金仓自带的图形工具创建数据库时默认的排序规则是zh.CN.UTF-8字符分类同样是zh.CN.UTF-8。而 Navicat 这边默认值可能是C或者en_US.UTF-8具体取决于客户端环境和所选模板。排序规则为C时数据库按字节序做字符串比较规则简单、执行效率高对索引的稳定性也更好zh.CN.UTF-8是按中文本地化规则做拼音和笔画排序更智能但排序路径更长而且一旦源库和目标库不太好做关联查询时可能出现排序结果不一致或者索引走不上的情况。另一个实际问题是中文本地化排序在部分金仓版本里对LIKE查询的支持不够稳定遇到%关键词%这种带通配符的模糊匹配执行计划会偏保守。在金仓的场景下我个人的习惯是新建库统一用C。原因很简单业务系统里的排序需求通常最终落在应用层数据库层用C排序不容易出现两边库排序结果对不上的情况。如果在迁移时发现两边的排序规则不一致尽量改库不要靠应用去适配。3.3 排序规则不一致的典型故障有人问不就是 order by 的顺序不一样吗真不止。排序规则不一致先出现的往往是ORDER BY结果和源库对不上紧接着是索引失效——因为 B-tree 索引的键顺序依赖排序规则规则变了优化器会认为已有索引不适用于当前排序要求直接走全表扫描。再严重一些涉及分区表、或者源表和目标表做 join 时两边 collation 不同数据库会直接报错ERROR: could not identify collation for join这个错误在 Navicat 里会原样显示在消息窗口看到它的第一反应就应该是去检查两张表的排序规则是否一致。我遇到过一次排查了半天 join 条件最后发现是两边的库一个用的zh.CN.UTF-8、一个用的C把其中一边重建库后才恢复。3.4 从金仓自带工具迁移过来的库字符集陷阱怎么处理如果你手上已经有一个用金仓自带工具建好的库字符集是zh.CN.UTF-8又不想重建我的建议是分两步走。第一步用 Navicat 连上这个库先执行一段 SQL 确认当前实际参数select datname, pg_encoding_to_char(encoding) as encoding, datcollate, datctype from pg_database where datname current_database();这条 SQL 读的是 pg_database 系统表在金仓的兼容层里同样能跑。encoding列显示实际字符集datcollate和datctype显示排序规则和字符分类。拿到结果后和源库比对一下这三个字段。如果源库和目标库的datcollate不一致建议把目标库改成一致再导入数据。第二步在 Navicat 的「高级」选项卡里确认连接编码为 UTF-8并在数据库属性里把默认字符集设为 UTF8。如果库已经建好字符集和排序规则是没法直接改的只能重建库或者用pg_dump导出后重新导入到新库。所以最省事的方法还是建库时就选对后面不需要吃这个苦。4. 转储 SQL、复制插入语句、执行查询日常迁移操作三件套4.1 转储 SQL 文件导出前先分清 schema连接打通、库也建好后最常用的就是「转储 SQL 文件」。右键数据库选「转储 SQL 文件」Navicat 会弹出保存对话框同时有几个勾选项结构、数据、触发器、扩展等。默认全勾问题不大但要注意一个坑人大金仓默认的数据库是带publicschema 的转储文件里会带CREATE SCHEMA public和 extension 创建语句导入到新库时如果目标库已经建过这些对象会报已存在的错。我的做法是转储之前先确认目标库的状态。如果是空库就直接导入如果目标库已经有对象就在对话框里去掉「创建 schema」和「扩展」这两项只保留表和数据的创建语句。另外转储完成后用文本编辑器打开 SQL 文件看一下头部确认第一段语句的类型心里有数导入时就不会对报错感到意外。4.2 复制为插入语句适合小表快速搬运转储 SQL 适合全库级迁移但有时候我只想挪一张表、或者把某几条数据搬到测试环境这时候用「复制为插入语句」更快。操作路径是在数据表上右键打开表数据选中若干行右键选「复制为插入语句」Navicat 会生成一串 INSERT 语句直接粘贴到目标库的查询窗口执行即可。这项功能在数据量小的时候很好用比如配置表、字典表几百行数据几秒钟就挪过去了。但是要注意数据量大就别用这个方式。我有一次复制一张二十万行的日志表Navicat 直接把 INSERT 语句拼接成一个超长文本再执行的时候不仅内存吃紧SQL 编辑器的渲染也明显卡顿。超过两三万行建议直接用「数据传输」工具在表之间做批量搬运或者导出 CSV 再导回。4.3 执行 SQL 语句查询窗口里的几个顺手用法执行 SQL 是常规操作但有几个使用习惯值得说一下。第一个Navicat 的查询窗口可以只执行选中的部分语句不用每次都把整个脚本跑一遍。调试 SQL 的时候我只选中要处理的那一段再按运行避免把前面建临时表的语句重复执行。第二个如果脚本里有事务记得在窗口顶部写好BEGIN;和COMMIT;Navicat 不会帮你自动包事务。第三个删除或更新操作前先执行同条件的 SELECT确认影响范围我吃过一次没写 WHERE 条件的亏从那以后 UPDATE 和 DELETE 前必定先查一眼。-- 先看影响行数再加 WHERE 执行 UPDATE select count(*) from business_order where status F;这条 SQL 本身没有特别之处但养成先 count 再 update 的习惯在迁移数据时可以帮你少出几次事故。4.4 转储前用 Navicat 自查一下源库状态在正式的转储操作前我通常会先检查三件事数据库连接是否空闲、有没有长事务在跑、表数量是否和预期一致。金仓和 PostgreSQL 一样pg_stat_activity系统表能直接查到后台会话Navicat 里有对应的「进程列表」查看面板。如果发现别的会话占着锁转储出来的数据可能是某个旧快照容易导致导出的数据不完整。自查这一步不是必须但对于生产库的备份操作多花两分钟换一份可靠的数据文件值得。5. 避坑与常见问题连接失败、乱码和权限的五个现场5.1 端口填 5432一直提示无法连接现象Navicat 测试连接提示connection refused或者超时服务端明明已经启动。 原因人大金仓默认监听端口是 54321很多同事以前连的是 PostgreSQL惯性把端口写成 5432。另外金仓如果部署在 Docker 里容器端口映射可能把 54321 映射成了宿主机的另一个端口需要先用docker port确认实际对外端口。 解决确认服务端配置文件里的port参数金仓的配置文件一般在安装目录的data下Docker 环境则用docker ps查看端口映射。修改后重新测试连接。5.2 连接成功但中文显示乱码现象Navicat 里查询出来的中文全是乱码或者在 Navicat 里写入的中文到业务系统里读出来是乱码。 原因客户端连接编码和数据库字符集不一致。数据库端是 UTF8Navicat 连接的高级选项中编码没设置或设成了 GBK字节流在客户端被错误解码。 解决编辑连接在高级选项卡里把编码改为 UTF-8。另外检查一下连接初始化语句里有没有执行过SET NAMES金仓兼容 PG 协议不需要也不建议执行 MySQL 风格的SET NAMES保持连接编码和库编码一致即可。5.3 连接成功但转储 SQL 时报权限不足现象数据库可以正常访问右键转储 SQL 文件时弹出permission denied for schema xxx。 原因当前账号对要转储的对象没有对应权限。金仓的权限模型继承自 PG连接权限和对象权限是分开的能连上不代表能导出。 解决在源库上对账号授权或者直接使用具备超级权限的账号执行转储。临时授权的命令是grant usage on schema public to your_user; grant all on all tables in schema public to your_user;注意后面这条只对有ALL TABLES的节点生效新建的表需要再授权一次如果不想逐张处理可以授权给该用户的默认权限。5.4 复制为插入语句操作大表Navicat 卡死现象选中几万行数据执行「复制为插入语句」软件长时间无响应。 原因Navicat 要先把所选行拼成一个完整的 SQL 文本行数多、字段多时拼接耗时和内存占用都会暴涨界面等待反馈不及时观感就是卡死。 解决小表用复制为插入语句大数据量改用「数据传输」向导把源表直接同步到目标库或者导出成 CSV 再导入。操作前先选中目标行数较少的数据避免全选。5.5 旧版本 Navicat 连接报认证协议错误现象连接金仓时报unsupported frontend protocol或者password authentication failed但密码肯定是正确的。 原因金仓低版本或特殊编译版本对认证方式的支持和老版 Navicat 使用的 PG 驱动不完全兼容另外金仓在安装时如果选了特定加密方式老驱动可能不认识。 解决优先确认金仓服务端pg_hba.conf中的认证方式建议使用md5或scram-sha-256金仓默认支持这两类。然后升级 Navicat 到较新版本新版本内置的 PG 驱动对这两种认证方式支持更稳定。不要在这时候去调金仓的加密算法除非你能确认所有客户端都同步升级。6. 验证连接与进阶操作把 Navicat 用成金仓的稳定入口连接配置完成、数据库也建好了很多人觉得能连上就行但我建议新环境第一次上手时走一遍验证流程把不确定性留在初始阶段别等到交付前夜再暴露问题。第一步是验证版本和编码环境。在 Navicat 的查询窗口执行select version();金仓环境下返回的结果会包含KingbaseES字样和版本号顺便看一眼返回结果里的字符集信息是否和预期一致。第二步是例行巡检三张视图pg_database看库级编码和排序规则pg_stat_activity看是否有长事务pg_tables看表数量是否对得上。这套组合我一般每次接新环境都跑一遍时间成本不到三分钟但能把字符集不一致、事务残留、缺表漏表这几类坑提前排除。进阶一点可以把常用操作存成 Navicat 的查询文件。比如把「查会话、查锁、查表大小、查阻塞」四段 SQL 存成一个巡检.sql文件以后每次进环境只需要打开这个文件改一下库名就能跑。Navicat 的查询窗口支持多语句同时执行结果集分别展示比一条条敲要快得多。还有一个习惯值得推荐把 Navicat 和金仓自带工具配合使用而不是二选一。我用 Navicat 做开发和日常运维因为它对 PostgreSQL 协议兼容得确实顺但遇到服务端资源占用异常或者底层配置修改的场景我会切到金仓自带的管理工具去看节点状态。两个工具读的是同一个数据库并不冲突。回到这条连接本身配置一次固定下来之后Navicat 就成了我面对金仓的稳定入口。从那以后我每接一个金仓环境第一件事就是检查端口、编码、排序规则三件套确认无误再开始导入数据再没有出现过首次交付时的乱码和排序翻车。希望帮到你。本文还有配套的精品资源点击获取 Navicat连接人大金仓KingbaseES实战：从建连到SQL转储避坑指南
简介一份面向数据库管理初学者的图文操作指南围绕使用Navicat连接国产人大金仓数据库的完整流程展开系统讲解从工具下载安装、创建连接、配置账号密码到新建数据库、转储SQL文件、复制插入语句及执行SQL语句等核心操作。文档同时针对字符集和排序规则给出明确建议可帮助读者规避乱码问题并理解连接配置中的关键细节。包体为单个docx文档大小约1.62MB内容结构清晰、步骤一目了然适合需要快速上手Navicat与人大金仓协同工作的运维工程师、数据处理人员或数据库初学者。该资源已有1279人学习下载除了完整的操作步骤说明还包含使用官方工具与Navicat的对比提示、权限与安全注意事项等实用经验便于读者在实际项目中灵活选用连接方式提升国产数据库的管理效率。1. Navicat 连人大金仓为什么值得搭这一条连接很多第一次接触人大金仓的同事习惯直接用 KingbaseES 自带的图形工具觉得官方工具总不会错。但我自己连着做了两个迁移项目之后反而更推荐用 Navicat 去连金仓——不是因为官方工具不好而是因为金仓兼容 PostgreSQL 协议Navicat 对 PG 生态的连接、排查和 SQL 编写支持都足够成熟界面也比自带工具更顺手。这条连接打通之后日常建库、导数据、调试 SQL 都能在一套工具里完成不用在几个客户端之间来回切换。这篇文章面向的是实施工程师、DBA 和数据迁移人员把从下载安装、建连接、建库到转储 SQL 的完整链路过一遍并把我踩过的排序规则、权限、端口这些坑一并说清楚。2. 装好 Navicat 并建第一个连接端口、驱动和账号是三个关键点2.1 下载安装官网拿安装包注意版本位数Navicat 的下载可以直接走官网Windows 环境下选择 Navicat Premium 的 x64 安装包例如navicat161_premium_cs_x64.exe。下载时注意两点第一操作系统是 32 位还是 64 位现在金仓服务端基本都在 x64 环境客户端也建议直接用 x64 版本避免装出 32 位后在大表操作时内存受限第二Navicat Premium 是 All-in-One 的客户端支持 MySQL、PostgreSQL、Oracle、SQL Server 等连人大金仓时我们走的是 PostgreSQL 通道所以不需要额外装金仓专用版。安装过程没有特别要说的一路下一步即可。需要注意安装路径不要放在带中文的目录下Navicat 在某些中文路径场景下会出现莫名其妙的加载异常虽然不常见但没必要去赌这个概率。2.2 连接前先确认三件事端口、驱动、账号在打开 Navicat 创建连接之前我建议先确认三个信息避免连不上时来回猜确认项常见值说明服务器 IP测试环境或生产环境的 IP金仓和客户端能互通是前提端口54321人大金仓默认端口是 54321不是 PostgreSQL 的 5432这点非常容易踩坑账号/密码由 DBA 分配的账号金仓默认有 SYSTEM 账号但实际项目一般会单独建业务账号确认端口时可以直接在客户端机器上敲一下telnet 192.168.1.100 54321如果端口不通先看防火墙和安全组如果通了会出现连接成功的空窗口说明网络层面没问题。我一般会在这一步多做一件事用ping确认 IP 能通再用telnet确认端口能通两个都过了再开 Navicat排错范围会小很多。2.3 创建连接选对连接类型填入连接信息打开 Navicat点击左上角「连接」下拉列表里没有写人大金仓的选项但我们不需要选MongoDB或MySQL而是选PostgreSQL。理由是人大金仓 KingbaseES 的对外协议兼容 PostgreSQLNavicat 的 PostgreSQL 驱动可以完成握手。连接窗口里需要填这几项连接名自己能识别的名字比如金仓-UAT主机金仓服务器的 IP 或域名端口默认 54321初始数据库可以先填test或者template1如果不知道有哪些库就留空用户名和密码DBA 分配的账号填完之后可以先不点「确定」点一下「测试连接」。如果弹窗提示连接成功说明底层通了如果弹的是认证失败优先检查密码其次查服务端的认证配置。这里有一个细节Navicat 在连接 PostgreSQL 协议时高级选项卡里有一项「编码」建议直接选UTF-8。金仓的字符集默认就是 UTF-8客户端编码不一致是后面乱码最常见的源头。连接保存后左侧列表会出现这个连接实例展开之后能看到数据库列表、表、视图这些对象。到这里Navicat 连金仓这条链路已经打通了。3. 创建数据库排序规则不一致乱码会跟你到迁移完成3.1 新建数据库时看到的三个下拉框分别管什么连接建好之后右键连接实例选择「新建数据库」会看到名称、所有者、字符集、排序规则、字符分类这几个字段。很多人在这里直接点「确定」等到迁移数据时才发现问题那时候再改库的编码和排序规则就非常被动了。Navicat 新建 PostgreSQL 类型数据库时关键的三个选项是选项作用建议字符集决定数据库用什么编码存数据UTF8金仓和 Navicat 默认都认这个排序规则决定 ORDER BY、索引排序用哪套规则建议 C理由见下文字符分类决定字符比较和分类逻辑和排序规则保持一致如果你看到的选项名是LC_COLLATE和LC_CTYPE也不用慌金仓兼容 PostgreSQL这两个参数本质上就是排序规则和字符分类的底层实现。Navicat 的图形界面把翻译和原生参数混合在一起有时候字段名会随版本变化但逻辑是一致的。3.2 C 和 zh.CN.UTF-8 到底差在哪这是我在金仓迁移项目里被问得最多的问题也是最容易翻车的位置。人大金仓自带的图形工具创建数据库时默认的排序规则是zh.CN.UTF-8字符分类同样是zh.CN.UTF-8。而 Navicat 这边默认值可能是C或者en_US.UTF-8具体取决于客户端环境和所选模板。排序规则为C时数据库按字节序做字符串比较规则简单、执行效率高对索引的稳定性也更好zh.CN.UTF-8是按中文本地化规则做拼音和笔画排序更智能但排序路径更长而且一旦源库和目标库不太好做关联查询时可能出现排序结果不一致或者索引走不上的情况。另一个实际问题是中文本地化排序在部分金仓版本里对LIKE查询的支持不够稳定遇到%关键词%这种带通配符的模糊匹配执行计划会偏保守。在金仓的场景下我个人的习惯是新建库统一用C。原因很简单业务系统里的排序需求通常最终落在应用层数据库层用C排序不容易出现两边库排序结果对不上的情况。如果在迁移时发现两边的排序规则不一致尽量改库不要靠应用去适配。3.3 排序规则不一致的典型故障有人问不就是 order by 的顺序不一样吗真不止。排序规则不一致先出现的往往是ORDER BY结果和源库对不上紧接着是索引失效——因为 B-tree 索引的键顺序依赖排序规则规则变了优化器会认为已有索引不适用于当前排序要求直接走全表扫描。再严重一些涉及分区表、或者源表和目标表做 join 时两边 collation 不同数据库会直接报错ERROR: could not identify collation for join这个错误在 Navicat 里会原样显示在消息窗口看到它的第一反应就应该是去检查两张表的排序规则是否一致。我遇到过一次排查了半天 join 条件最后发现是两边的库一个用的zh.CN.UTF-8、一个用的C把其中一边重建库后才恢复。3.4 从金仓自带工具迁移过来的库字符集陷阱怎么处理如果你手上已经有一个用金仓自带工具建好的库字符集是zh.CN.UTF-8又不想重建我的建议是分两步走。第一步用 Navicat 连上这个库先执行一段 SQL 确认当前实际参数select datname, pg_encoding_to_char(encoding) as encoding, datcollate, datctype from pg_database where datname current_database();这条 SQL 读的是 pg_database 系统表在金仓的兼容层里同样能跑。encoding列显示实际字符集datcollate和datctype显示排序规则和字符分类。拿到结果后和源库比对一下这三个字段。如果源库和目标库的datcollate不一致建议把目标库改成一致再导入数据。第二步在 Navicat 的「高级」选项卡里确认连接编码为 UTF-8并在数据库属性里把默认字符集设为 UTF8。如果库已经建好字符集和排序规则是没法直接改的只能重建库或者用pg_dump导出后重新导入到新库。所以最省事的方法还是建库时就选对后面不需要吃这个苦。4. 转储 SQL、复制插入语句、执行查询日常迁移操作三件套4.1 转储 SQL 文件导出前先分清 schema连接打通、库也建好后最常用的就是「转储 SQL 文件」。右键数据库选「转储 SQL 文件」Navicat 会弹出保存对话框同时有几个勾选项结构、数据、触发器、扩展等。默认全勾问题不大但要注意一个坑人大金仓默认的数据库是带publicschema 的转储文件里会带CREATE SCHEMA public和 extension 创建语句导入到新库时如果目标库已经建过这些对象会报已存在的错。我的做法是转储之前先确认目标库的状态。如果是空库就直接导入如果目标库已经有对象就在对话框里去掉「创建 schema」和「扩展」这两项只保留表和数据的创建语句。另外转储完成后用文本编辑器打开 SQL 文件看一下头部确认第一段语句的类型心里有数导入时就不会对报错感到意外。4.2 复制为插入语句适合小表快速搬运转储 SQL 适合全库级迁移但有时候我只想挪一张表、或者把某几条数据搬到测试环境这时候用「复制为插入语句」更快。操作路径是在数据表上右键打开表数据选中若干行右键选「复制为插入语句」Navicat 会生成一串 INSERT 语句直接粘贴到目标库的查询窗口执行即可。这项功能在数据量小的时候很好用比如配置表、字典表几百行数据几秒钟就挪过去了。但是要注意数据量大就别用这个方式。我有一次复制一张二十万行的日志表Navicat 直接把 INSERT 语句拼接成一个超长文本再执行的时候不仅内存吃紧SQL 编辑器的渲染也明显卡顿。超过两三万行建议直接用「数据传输」工具在表之间做批量搬运或者导出 CSV 再导回。4.3 执行 SQL 语句查询窗口里的几个顺手用法执行 SQL 是常规操作但有几个使用习惯值得说一下。第一个Navicat 的查询窗口可以只执行选中的部分语句不用每次都把整个脚本跑一遍。调试 SQL 的时候我只选中要处理的那一段再按运行避免把前面建临时表的语句重复执行。第二个如果脚本里有事务记得在窗口顶部写好BEGIN;和COMMIT;Navicat 不会帮你自动包事务。第三个删除或更新操作前先执行同条件的 SELECT确认影响范围我吃过一次没写 WHERE 条件的亏从那以后 UPDATE 和 DELETE 前必定先查一眼。-- 先看影响行数再加 WHERE 执行 UPDATE select count(*) from business_order where status F;这条 SQL 本身没有特别之处但养成先 count 再 update 的习惯在迁移数据时可以帮你少出几次事故。4.4 转储前用 Navicat 自查一下源库状态在正式的转储操作前我通常会先检查三件事数据库连接是否空闲、有没有长事务在跑、表数量是否和预期一致。金仓和 PostgreSQL 一样pg_stat_activity系统表能直接查到后台会话Navicat 里有对应的「进程列表」查看面板。如果发现别的会话占着锁转储出来的数据可能是某个旧快照容易导致导出的数据不完整。自查这一步不是必须但对于生产库的备份操作多花两分钟换一份可靠的数据文件值得。5. 避坑与常见问题连接失败、乱码和权限的五个现场5.1 端口填 5432一直提示无法连接现象Navicat 测试连接提示connection refused或者超时服务端明明已经启动。 原因人大金仓默认监听端口是 54321很多同事以前连的是 PostgreSQL惯性把端口写成 5432。另外金仓如果部署在 Docker 里容器端口映射可能把 54321 映射成了宿主机的另一个端口需要先用docker port确认实际对外端口。 解决确认服务端配置文件里的port参数金仓的配置文件一般在安装目录的data下Docker 环境则用docker ps查看端口映射。修改后重新测试连接。5.2 连接成功但中文显示乱码现象Navicat 里查询出来的中文全是乱码或者在 Navicat 里写入的中文到业务系统里读出来是乱码。 原因客户端连接编码和数据库字符集不一致。数据库端是 UTF8Navicat 连接的高级选项中编码没设置或设成了 GBK字节流在客户端被错误解码。 解决编辑连接在高级选项卡里把编码改为 UTF-8。另外检查一下连接初始化语句里有没有执行过SET NAMES金仓兼容 PG 协议不需要也不建议执行 MySQL 风格的SET NAMES保持连接编码和库编码一致即可。5.3 连接成功但转储 SQL 时报权限不足现象数据库可以正常访问右键转储 SQL 文件时弹出permission denied for schema xxx。 原因当前账号对要转储的对象没有对应权限。金仓的权限模型继承自 PG连接权限和对象权限是分开的能连上不代表能导出。 解决在源库上对账号授权或者直接使用具备超级权限的账号执行转储。临时授权的命令是grant usage on schema public to your_user; grant all on all tables in schema public to your_user;注意后面这条只对有ALL TABLES的节点生效新建的表需要再授权一次如果不想逐张处理可以授权给该用户的默认权限。5.4 复制为插入语句操作大表Navicat 卡死现象选中几万行数据执行「复制为插入语句」软件长时间无响应。 原因Navicat 要先把所选行拼成一个完整的 SQL 文本行数多、字段多时拼接耗时和内存占用都会暴涨界面等待反馈不及时观感就是卡死。 解决小表用复制为插入语句大数据量改用「数据传输」向导把源表直接同步到目标库或者导出成 CSV 再导入。操作前先选中目标行数较少的数据避免全选。5.5 旧版本 Navicat 连接报认证协议错误现象连接金仓时报unsupported frontend protocol或者password authentication failed但密码肯定是正确的。 原因金仓低版本或特殊编译版本对认证方式的支持和老版 Navicat 使用的 PG 驱动不完全兼容另外金仓在安装时如果选了特定加密方式老驱动可能不认识。 解决优先确认金仓服务端pg_hba.conf中的认证方式建议使用md5或scram-sha-256金仓默认支持这两类。然后升级 Navicat 到较新版本新版本内置的 PG 驱动对这两种认证方式支持更稳定。不要在这时候去调金仓的加密算法除非你能确认所有客户端都同步升级。6. 验证连接与进阶操作把 Navicat 用成金仓的稳定入口连接配置完成、数据库也建好了很多人觉得能连上就行但我建议新环境第一次上手时走一遍验证流程把不确定性留在初始阶段别等到交付前夜再暴露问题。第一步是验证版本和编码环境。在 Navicat 的查询窗口执行select version();金仓环境下返回的结果会包含KingbaseES字样和版本号顺便看一眼返回结果里的字符集信息是否和预期一致。第二步是例行巡检三张视图pg_database看库级编码和排序规则pg_stat_activity看是否有长事务pg_tables看表数量是否对得上。这套组合我一般每次接新环境都跑一遍时间成本不到三分钟但能把字符集不一致、事务残留、缺表漏表这几类坑提前排除。进阶一点可以把常用操作存成 Navicat 的查询文件。比如把「查会话、查锁、查表大小、查阻塞」四段 SQL 存成一个巡检.sql文件以后每次进环境只需要打开这个文件改一下库名就能跑。Navicat 的查询窗口支持多语句同时执行结果集分别展示比一条条敲要快得多。还有一个习惯值得推荐把 Navicat 和金仓自带工具配合使用而不是二选一。我用 Navicat 做开发和日常运维因为它对 PostgreSQL 协议兼容得确实顺但遇到服务端资源占用异常或者底层配置修改的场景我会切到金仓自带的管理工具去看节点状态。两个工具读的是同一个数据库并不冲突。回到这条连接本身配置一次固定下来之后Navicat 就成了我面对金仓的稳定入口。从那以后我每接一个金仓环境第一件事就是检查端口、编码、排序规则三件套确认无误再开始导入数据再没有出现过首次交付时的乱码和排序翻车。希望帮到你。本文还有配套的精品资源点击获取