（二）利用Navicat实现MSSQL到PostgreSQL的高效数据迁移
1. 为什么选择Navicat进行跨数据库迁移？
当你需要把数据从MSSQL搬到PostgreSQL时，Navicat绝对是个省心利器。我做过不下20次这类迁移，最头疼的就是数据类型不兼容、主键冲突这些坑。Navicat最让我满意的就是它能自动处理大部分数据类型转换，比如把MSSQL的datetime转成PostgreSQL的timestamp，varchar转text这些常见情况根本不用手动干预。
记得去年给某电商平台做迁移时，他们有个关键订单表包含87万条记录。用原生SQL脚本折腾了三天都没搞定，换Navicat只用了2小时17分钟就完整迁移，连jsonb字段里的特殊字符都完美保留。工具会自动生成类似这样的转换逻辑：
-- 自动转换示例 CAST(source_column AS target_type) COALESCE(NULLIF(source_column,''), default_value)2. 迁移前的关键准备工作
2.1 连接配置的隐藏技巧
新建连接时有个细节90%的人会忽略：连接超时设置。MSSQL默认是30秒，但迁移大表时建议调到300秒以上。我有次迁移300GB的日志表，就因为这个参数没调导致反复中断。具体操作是在连接属性→高级里修改：
Connect Timeout=300 Query Timeout=600另一个血泪教训是编码设置。PostgreSQL默认用UTF-8，而MSSQL可能是GBK。有次迁移后中文全变问号，最后发现要在Navicat的PostgreSQL连接属性里强制指定：
client_encoding=UTF82.2 结构对齐检查清单
正式开始数据传输前，建议先用这个检查表确认结构一致性：
- 主键约束：确保两边表都有相同的主键设置
- 默认值：特别是时间戳字段的CURRENT_TIMESTAMP
- 索引数量：我遇到过PostgreSQL比MSSQL少3个索引的情况
- 字段允许NULL：MSSQL允许NULL的字段可能在PostgreSQL被设为NOT NULL
3. 数据传输实战操作指南
3.1 表选择的高级策略
点击"自定义选择表"时，别急着全选。建议按这个优先级分批迁移：
- 先迁维度表（用户、商品等基础数据）
- 再迁配置表（系统参数、字典表）
- 最后迁事实表（订单、日志等大数据量表）
有个实用技巧：在表选择界面右键可以按行数排序，这样能优先迁移小表测试流程。我习惯先选5-10个小表试跑，确认没问题再处理大表。
3.2 选项配置的黄金组合
这些选项组合经过我多次验证最稳定：
| 选项 | 推荐设置 | 原因 |
|---|---|---|
| 创建表 | 不勾选 | 已用AWS工具完成结构迁移 |
| 删除记录 | 勾选 | 避免重复数据 |
| 转换对象名 | 小写 | PostgreSQL对大小写敏感 |
| 错误继续 | 勾选 | 避免因单条错误中断 |
| 批处理 | 500条/批 | 平衡性能与稳定性 |
特别注意：如果遇到自增ID冲突，需要在高级里勾选重置序列选项。
4. 迁移后的验证与优化
4.1 数据一致性检查三招
- 行数比对：在Navicat里对两个数据库执行
SELECT COUNT(*) FROM table_name - 抽样校验：随机查10条记录对比关键字段
- 聚合验证：对比
SELECT SUM(amount) FROM orders
4.2 性能调优必做项
迁移完成后建议立即执行：
- ANALYZE：更新统计信息
ANALYZE VERBOSE table_name; - 索引重建：特别是迁移过程中产生的临时索引
- VACUUM：回收空间
VACUUM FULL VERBOSE table_name;
最近一次给银行系统迁移时，做完这些优化后查询速度提升了6倍。有个关键报表从原来的47秒降到8秒，DBA团队都惊了。
5. 常见问题解决方案
5.1 错误代码处理手册
这些错误我遇到最多：
- 错误23505：唯一约束冲突 → 检查是否有重复主键
- 错误22P02：数据类型不匹配 → 在选项里开启严格类型转换
- 错误54000：语句超时 → 调整PostgreSQL的statement_timeout参数
5.2 特殊字段处理技巧
- XML字段：需要先在MSSQL用CONVERT转成NVARCHAR(MAX)
- 地理空间数据：PostGIS和MSSQL的空间类型语法不同，建议先用文本格式迁移
- 大二进制文件：单个BLOB超过1GB时，建议分批次传输
上个月处理一个医疗影像系统时，有个3.2GB的DICOM文件一直失败。后来发现要在Navicat的传输设置里把包大小从默认的1MB调到10MB才成功。