简介《人大金仓-KingbaseES GIS数据迁移方案》面向数据库管理员、地理信息集成实施人员以及需要把空间数据迁入国产数据库的技术团队围绕金仓数据库V8.6的空间数据管理场景梳理从主流GIS平台及通用数据格式向KingbaseES迁移的可行路径。压缩包共1个PDF文件约2.76MB便于离线查阅和团队传阅。内容涵盖空间数据存储与处理能力、基于KDTS工具的抽取转换加载流程、迁移结果验证和常见问题汇总并介绍ArcGIS、GeoScene软件直连迁移、SuperMap平台迁移以及第三方通用格式入库方法。文档按能力概述、平台迁移、结果验证与答疑组织目录清晰可快速定位ArcGIS、SuperMap等不同来源的操作章节。已有136人学习适合在方案选型、实施准备和迁移排错时参考帮助读者理解迁移步骤、验证要点、兼容性判断与风险处理思路。1. 换库后地图空白的那次故障GIS 迁移真正的难点不在数据搬运凌晨两点被叫起来处理一次换库后的故障图层表都在要素一条不少地图服务一打开却是一片空白。事后定位问题既不在数据也不在驱动而是空间字段与地理数据库的注册关系没跟着搬过去。这类问题在 KingbaseES GIS 数据迁移方案里被反复强调——迁移的目标从来不是「把表搬过去」而是搬完之后 ArcGIS、SuperMap 这些平台仍然能把目标库认成自己的地理数据库能正常读几何、读栅格、读切片缓存。这份 V8.6 的方案文档把路径拆成三条ArcGIS/GeoScene 平台侧直连迁移、KDTS 工具大批量迁移、SuperMap 与通用格式文件入库每条都配了验证方法和 FAQ。它适合正在做存量 GIS 系统换库的 DBA、GIS 实施人员和交付验收方尤其是手里只有一份 Oracle Spatial 备份、连平台都不在的那种场景。2. KGIS 的存储分层矢量落 geom 字段、栅格只存元数据、三维走另一条通道迁移方案的第一步不是打开工具而是搞清楚目标库准备用哪种形态接住源端的数据。KingbaseES 通过 KGIS 插件提供空间能力它和 ArcGIS 那套 SDE 体系并不是一一对应的混着理解会在后面每一步都埋雷。文档第 2 章把 GIS 数据分成矢量、栅格、三维、切片缓存四类这个分类直接决定了后面用哪条迁移通道、拿什么口径验收。2.1 矢量数据一个图层一张表geom 字段是唯一入口矢量数据在源端可能是 .shp、.dwg、.dxf、.kml、.geojson落到库里统一变成「一张表 一个空间字段」文档示例里这个字段叫 geom。仓库里存的是几何对象本身坐标系信息存在空间参考字典里通过 SRID 关联。这意味着两件事一是迁移时不能只搬业务字段几何列的类型和 SRID 必须一并正确落地二是目标端的空间元数据视图里必须有对应登记否则应用拿到的是一个「有几何列但不知道是什么几何」的普通表。源端如果是 Oracle Spatial 上的 ArcGIS 地理数据库几何列的类型一般是 ST_GEOMETRY。迁移前我习惯先跑一遍盘点把图层规模和几何列摸清楚。-- 源端 Oracle找出所有带 ST_GEOMETRY 列的图层表按行数倒序 SELECT c.table_name, c.column_name, t.num_rows FROM user_tab_columns c JOIN user_tables t ON t.table_name c.table_name WHERE c.data_type ST_GEOMETRY ORDER BY t.num_rows DESC;data_type在不同 ArcGIS 版本下可能是ST_GEOMETRY或带 schema 前缀的类型名查不到时把条件放宽成LIKE %GEOMETRY%再看。num_rows取自统计信息很久没收集过统计的表会严重失真跑之前先做一次统计收集或者对大表直接count(*)抽样核对。这一步的价值在于提前知道哪些表要开大表拆分而不是等迁移跑到一半卡住再回头看。目标端要确认 KGIS 已就绪。插件启用方式随版本略有差异创建扩展或执行初始化脚本启用之后用下面几条语句确认空间字典和元数据视图可用-- 目标端 KingbaseES确认空间字典与图层元数据可见 SELECT current_database(), version(); SELECT count(*) FROM spatial_ref_sys; -- 为 0 说明坐标系字典没初始化 SELECT f_table_name, f_geometry_column, srid, type FROM geometry_columns LIMIT 20;spatial_ref_sys是坐标系字典空表意味着后面所有带 SRID 的几何都落不下去会直接报错。geometry_columns是图层登记视图迁移完成后要靠它确认每个图层的几何类型和 SRID 是否正确这条查询建议留到验收阶段再跑一遍做对比。2.2 栅格数据元数据入库像素文件留在文件系统文档对栅格的处理方式和很多人的直觉相反KGIS 并不把 tif、img 的像素塞进大字段而是把影像的实际存储路径、中心点、范围框、星历参数这类元数据存进表像素本体留在文件系统。这么设计的原因很实际——一个 2GB 的影像塞进大字段后任何一次带条件查询都可能把缓冲区拖垮而元数据入库可以先按范围框把候选集缩到几张再回文件系统取像素查询效率和存储成本都更可控。这条设计对迁移的影响经常被低估。栅格「迁移」实际上是两件事拷贝像素文件以及在目标端重新登记元数据。只做前者属性表里查得到记录但取像素时报找不到文件只做后者路径还指在源机目录上。所以栅格迁移一定要确认登记表里的路径列在文件搬完之后做一次路径重写具体写法在第 5 章的排查里给。2.3 三维数据与切片缓存别把瓦片往几何列里塞KGIS 支持 Z 维度和 M 维度也支持 TIN、POLYHEDRALSURFACE 这类三维对象建模并提供计算三维对象关系的函数。但文档明确划了一条线三维模型、倾斜摄影测量数据不按几何对象存而是按栅格那套方式处理。原因是倾斜摄影的产物本质上是海量瓦片加索引几何列装不下这种结构。切片缓存同理属于文件类型数据走文件系统或对象存储最合适。这条边界看着像常识实际交付里常出问题验收时按「库里的表数量」对账结果切片目录少拷了一半没人发现或者反过来把几十 GB 的瓦片目录硬塞进库备份窗口直接翻倍。我的做法是把验收口径拆成两套——库内数据验表和几何库外数据验文件数量与目录结构两套都对上才算迁移完成。2.4 迁移前先做一张资产盘点表把上面几类数据过一遍产出物是一张盘点表后面每一步都对着它推进。这份表不需要多漂亮但要能让实施、DBA、验收三方看同一份事实。数据类别源端典型形态目标端落点迁移通道验收方式矢量要素类Oracle Spatial 表 / shp业务表 geom 字段KDTS 或平台直连行数、几何有效性、范围框栅格影像tif / img 元数据元数据表 文件系统文件拷贝 重新登记记录数、路径可读、范围框三维对象TIN / 带 Z、M 的几何几何表KDTS维度与类型检查倾斜摄影/模型瓦片目录文件系统文件同步文件数、目录哈希切片缓存缓存目录文件系统文件同步层级完整性抽查盘点阶段还要顺带确认三件事源库字符集和目标库字符集是否一致、业务表里是否存在没有主键的表影响大表拆分、以及有多少张表的单表体量超过拆分阈值。这三项在 KDTS 配置参数时全都要用到提前问清楚比中途改配置省事得多。3. 平台侧直连迁移instance 写成「主机,端口」与 *.ecp 授权这两步别省平台侧直连适合图层不多、数据量不大的场景源库和目标库都能被 GIS 客户端连上用 ArcGIS/GeoScene 自带的异构库能力把要素类导过去。它的优点是操作直观、单表可控缺点是数据量大时慢得让人怀疑人生几百个图层跑一晚上是常事。文档把 KDTS 和平台直连并列判断标准就一条——量级和是否有平台可用。3.1 两条路径怎么选判断条件平台侧直连KDTS 工具迁移数据量单库几十 GB 以内TB 级、单表上亿行源端状态有在线的 GIS 平台只有数据库备份文件无平台图层数量少量要素类大量图层、批量任务迁移粒度单个要素类/要素集模式级、整库级主要风险大批量时中断、耗时不可控参数配置不当导致卡死实际项目里两条路常常混用主体数据走 KDTS几个体量小但结构特殊的图层比如带复杂域和子类型的要素类用平台导一遍反而更稳。3.2 建连接时最容易错的一步instance 不是数据库名在 ArcCatalog 里添加数据库连接时目标端填的不是数据库名而是实例地址。文档给的例子是192.168.4.30,5444——主机后面跟逗号再跟端口。这个格式要记住端口不是默认 5432 时必须显式带上漏了它客户端会按默认端口去连等超时之后报一个和网络、权限都无关的「Operation Failed」排查方向很容易跑偏。建连接之前先用命令行探一次活能省掉大半的扯皮。# 1) 探端口和认证是否通排除网络与防火墙问题 ksql -h 192.168.4.30 -p 5444 -U sde -d gisdb -c select version(); # 2) 看账号角色属性建企业级地理数据库需要足够的建表权限 ksql -h 192.168.4.30 -p 5444 -U sde -d gisdb -c \du-h是主机-p是端口漏了就走默认-U是用户-d是库名。第一条能通说明网络和认证没问题后面客户端连不上就只可能是实例格式、授权文件或地理数据库状态第二条看角色属性用普通业务账号去建地理数据库十有八九在建系统表那步失败。3.3 「启动地理数据库」和 *.ecp 授权两个必做动作连上之后还有两步缺一步后面全白干。第一步是启动地理数据库。在目录树里选中已连接的库右键执行「启动地理数据库」源库和目标库都要做。这一步的作用是让 ArcGIS 把普通数据库识别成地理数据库只有识别成功它才会去读写那套 SDE 系统表和元数据。跳过这一步库里有表有数据客户端也只当它是普通关系库图层列表是空的。第二步是授权文件。创建企业级地理数据库时选的授权文件必须是*.ecp格式文档特意点了这一条。实操里拿错文件的情况不少给的是.prvc或者一个改了后缀的文本文件客户端报授权错误但报错信息不会直说格式不对。拿到文件先看扩展名和内容头别等建库跑到一半才发现。3.4 平台之外的文件入库shp、geojson、dwg、tif 各有一坑不是所有数据都来自 GIS 平台。第三方交付的 shp 包、规划部门给的 dwg、无人机出的 tif都得单独处理几个点值得提前说。shp 的第一个坑是编码。中文属性用 GBK 存的 dbf导入后全是问号得在导入时显式指定编码或者先转成 UTF-8。第二个坑是字段名dbf 的字段名上限是 10 个字符超长会被截断导入后业务代码按原字段名查就会报列不存在。第三个坑是几何类型混杂一个 shp 里既有面又有线的情况虽然少见但遇到就直接失败。dwg/dxf 的问题是没有坐标系概念。CAD 图里的坐标只是一个数值导入时必须显式指定 SRID指定错了地图上能看到图形但位置偏到太平洋去这种错最难在数据层发现只能靠叠加底图比对。用 GDAL 的 OGR 走通用入库是常见做法下面这条命令覆盖了编码、空间字段名、SRID 和几何类型四个关键点ogr2ogr -f KingbaseES \ PG:host192.168.4.30 port5444 dbnamegisdb usersde password****** \ roads.shp \ -nln roads \ -lco GEOMETRY_NAMEgeom \ -lco FIDid \ -lco SRID4490 \ -nlt MULTILINESTRING \ --config SHAPE_ENCODING GBK-nln指定目标表名建议和源文件名保持一致便于追溯GEOMETRY_NAMEgeom把空间字段统一成 geom应用层改库时不用改代码FIDid显式建主键列后面做大表拆分和增量对比都靠它SRID4490是常见的 2000 国家大地坐标系按源数据实际情况改不要照抄-nlt强制几何类型避免混合类型入库失败SHAPE_ENCODING处理中文属性。如果目标环境没有对应的驱动退回用随 KGIS 提供的导入工具思路一样先定坐标系再定几何类型最后处理属性编码。tif 这类影像不要走矢量通道按栅格那套登记元数据、拷贝文件的路子来硬塞进去只会得到一堆无法查询的大字段。3.5 SuperMap 侧的差异点SuperMap 平台的迁移流程和 ArcGIS 类似都是建数据源连接、导入或复制数据集但有几个差异需要留意。一是数据源连接里要选对数据库类型选错之后连接能建立但读不到空间表二是字段类型映射SuperMap 的文本型、宽字符类型在目标端的长度可能被压缩导入后要抽样检查字段长度和内容截断三是它的系统表命名和 SDE 体系完全不同迁移后要按 SuperMap 自己的注册信息核对不能套用 ArcGIS 那套注册脚本。文档第 4 章给了 SuperMap 的迁移步骤和 FAQ实际做的时候建议先用两三个小数据集跑通全流程确认字段类型和坐标系都对再批量推。这种「先小后大」的习惯在任何平台的迁移里都成立。4. KDTS 的四个任务步骤与七个参数游标 100、批量 1000、提交 100MB 的调法KDTS 是这批迁移里的主力工具插件式加载数据库访问接口支持同异构数据源之间的结构迁移、全量迁移、列名映射和表数据过滤。它的使用流程是固定的四步选择数据源、选择模式、选择迁移对象、配置参数然后保存或保存并迁移。流程本身不难难的是参数怎么调以及每一步的边界条件。4.1 新建源与目标连接URL 生成规则和驱动选择新建连接要填的字段有连接名称、数据库类型、数据库版本、服务器地址、端口、用户名、密码、数据库、驱动、URL、连接参数。其中连接名称是自定义标识建议带上环境前缀比如prod_ora_gis迁移任务多的时候不容易选错。驱动和 URL 是自动联动的填完地址、端口、库名之后源库是 Oracle 的要选SID还是ServiceName这两个选错连不上——单实例一般用 SID集群环境用 ServiceName 更稳因为集群里各节点的 SID 可能不一致而 ServiceName 是一致的。目标库是 KingbaseES 的要在JDBC和UnixDomainSocket之间选迁移工具和目标库装在同一台 Linux 服务器上时用 socket省掉网络栈开销大批量写入时提升明显跨机部署只能选 JDBC。连接参数按数据库做适配可以自己加。比较实用的两个是连接超时和 socket 超时网络抖动大的环境里把它们调大能避免长事务被中途掐断。4.2 选择模式与迁移对象包含与排除的三种填法模式这一步有个硬性要求至少要选一个模式否则直接报错。如果源端有系统模式需要一并迁勾上「包含系统模式」但 GIS 场景下一般不建议迁 SDE 的系统表那套元数据在目标端要靠注册脚本重建搬过去反而会导致状态混乱。选完模式还要选表如果这一步没选任何表工具会认为不需要迁移对象跳过对象选择直接进参数配置——很多人以为是自己点快了其实这是设计行为。指定表和排除表支持三种填法输入框直接输表名多个用逗号分隔回车确认、从列表选择、从文件导入。第三种在表多的时候最省事先从工具下载导入模板按模板规则填好再导。排除模式特别适合处理碎片化的历史表# exclude_tables.txt —— 排除清单示例一行一个表名 # 优先排除日志表、临时表、归档表、以 _bak / _old / _tmp 结尾的表 sde.log_2021 sde.tmp_import_batch sde.roads_bak sde.poi_old模板的分隔符和表名大小写要严格按下载的模板来手工改格式是最常见的导入失败原因。表名大小写按源库实际写法填Oracle 里不加引号建的表在字典里是大写填小写会匹配不到。4.3 七个参数怎么调默认值不是万能值参数配置是整份方案里最需要经验的部分。文档给了默认值但默认值面向的是通用场景GIS 数据的大字段多、单表体量大几乎每一项都要动。参数默认值调大的后果调小的后果我的常用值源库游标读取记录数100源端 UNDO 压力大易触发快照过旧读取轮次多整体变慢大字段表 50窄表 500批量写入目标库记录数1000目标端锁等待、内存占用上升写入轮次多吞吐下降10002000每次批量提交大小100MB事务过大回滚代价高提交频繁日志压力大大字段多时降到 2050MBLOB 字段预读取大小4000Byte占用内存收益递减小于实际字段时多次读按实际影像/文本长度调大表拆分阈值行数未开单表过亿不拆必然超时拆得过碎调度开销上升500 万1000 万大表拆分最大块数未开块数过多反而拖慢大表拆不干净2050数据库连接数100源库连接打满、影响业务并行度不足816视源库余量大表拆分阈值还有「按大小」这一档对影像元数据、带大文本的表更适用。含大对象表的游标读取记录数要单独设因为大字段读取的代价和小字段完全不是一个量级。非对象设置里有主键、检查约束、唯一约束、外键、索引、触发器、自动转换对象名、注释默认全选。这里的经验是外键和触发器在大批量迁移时容易因为批次顺序失败可以第一轮先不迁等数据落完再单独补补的时候用脚本从源端导出 DDL 人工核对一遍。索引建议迁但超大表可以先迁数据后建索引能省一大截时间。表名和列名大小写默认「不变」这个默认值是对的。改成统一大写或小写之后应用层所有带引号的 SQL 都会失效回滚成本很高。4.4 表排序与大表拆分让问题早暴露表排序依据默认是「按行数和大字段大小交替」意思是大小表混着跑。这个默认策略的好处是前几十分钟就能看到成功和失败的样本不用等到最后才发现类型映射有问题。如果追求最短总时长可以改成按大小倒序但风险是前两个小时全在啃最大的表中途出错等于白跑。大表拆分要和索引配合。拆分依据是行数或大小时工具会按主键或可用索引切片如果表上没有合适的主键每一块都退化成全表扫描拆了比不拆还慢。所以盘点阶段查「没有主键的表」不是为了好看是为了在这一步做决策——要么先补主键要么把这类表放进排除清单单独处理。4.5 保存、执行与失败后的第一现场任务建好后有两个出口「保存」作为预迁移任务留着以后跑「保存并迁移」立刻执行。迁移结束看状态栏「完成」就是成功「失败」要点详情看日志。日志里高频出现的几类错误值得背下来源端报快照过旧ORA-01555说明 UNDO 不够或者游标读取太大类型映射失败通常是源端的自定义类型在目标端没有对应约束冲突多半是唯一约束或主键在源数据里本来就有重复数据。这几类问题的处理方式在第 5 章展开。4.6 迁移后注册那行 Python 脚本不能漏KDTS 迁完之后数据在库里但 ArcGIS 还不认。文档给的做法是在迁移结果目录result/时间戳/SDE/AcrpyRegisterScript/下找到acrpyRegisterWithGeodatabase.py拷到 ArcGIS 所在机器的 Python 目录下执行。# 1) 从迁移结果目录确认注册脚本存在 ls result/2021-12-02_15-15-15/SDE/AcrpyRegisterScript/ # 2) 拷到 ArcGIS 自带解释器目录示例路径按实际安装版本改 copy acrpyRegisterWithGeodatabase.py C:\Python27\ArcGIS10.8\这个脚本依赖 ArcPy必须用 ArcGIS 自带的解释器跑拿系统里另装的 Python 会直接报模块找不到。文档示例路径里带的是 ArcGIS 10.8 和 Python 2.7实际版本不同就按自己的安装目录改。脚本的具体入参以脚本内的 usage 说明为准通常是目标库连接信息加待注册的表或要素类清单。注册完再去 ArcCatalog 里刷新图层应该就能正常展开了。这一步是整条链路上最容易漏的也是第 1 章那个凌晨故障的直接原因。5. 避坑与排查注册、编码、大表卡死、栅格路径这五条血泪记录这些坑基本都是我在不同项目里真实踩过的按「现象 → 原因 → 解决」记下来遇到时能直接对照。5.1 数据一条不少ArcGIS 打开是空图层现象KDTS 状态显示完成用 ksql 查业务表行数和源端一致几何列也有值但 ArcGIS 连上目标库之后图层列表里什么都没有或者能看到表名但打不开。原因只迁了业务表没做地理数据库注册。SDE 那套系统表图层登记、表登记、列登记、项目元数据描述的是「哪张表是要素类、哪个列是几何、SRID 是多少」KDTS 把它们当普通表处理即便迁过去也是残缺的。ArcGIS 判断一个库是不是地理数据库看的就是这套元数据。解决在 ArcGIS 机器上执行注册脚本把迁移后的表注册成地理数据库对象。如果注册之后还打不开检查目标库里 SDE 模式是否存在、当前连接用户是否有该模式的读权限。另一个常见分支是源端表在 SDE 里注册为版本化要素类这类表迁移后需要额外处理版本表不能只跑基础注册。5.2 中文属性变问号字段名少了一截现象迁移完成后属性表里的中文全是问号或乱码或者业务代码报「列不存在」去库里一看字段名比原来短了。原因前者是字符集和编码问题——shp 的 dbf 用 GBK 存中文导入时按 UTF-8 解析就会乱库级编码如果建库时没定成 UTF-8后面改起来非常麻烦。后者是 dbf 的字段名 10 字符限制超长部分被截断而业务代码还按原字段名查。解决文件入库时显式指定编码SHAPE_ENCODINGGBK或者先用工具转成 UTF-8 再导。字段名截断没法在导入时绕过只能做一次字段名映射导入时用短名导入后在库里重命名成业务需要的长名再把映射关系交给应用层。建库阶段就把编码定死成 UTF-8这条没有后悔药。5.3 迁移跑到 60% 卡住源库开始告警现象任务进度长时间停在某个百分比不动源库监控上看到 UNDO 表空间使用率飙升最终任务失败日志里是快照过旧。原因游标读取记录数配得太大加上提交批次是 100MB 的默认值一个事务持有太久源库的回滚段撑不住。GIS 表往往带大字段同样行数的数据体积是普通业务表的好几倍默认参数在这种场景下很容易过载。解决把源库游标读取记录数降到 50每次批量提交大小降到 2050MB同时打开大表拆分阈值行数。如果源库还在承载业务把迁移窗口挪到低峰期并且限制数据库连接数不要和业务抢连接。改完参数先拿一张中等大小的表试跑确认稳定再推全量。5.4 栅格有记录取像素时报找不到文件现象栅格元数据表里记录数正确范围框也能查出来但应用按记录取像素时报文件不存在或者返回空。原因只迁了元数据没拷像素文件或者文件拷过去了但登记表里的路径还是源机的绝对路径。文档明确栅格存的是实际存储路径路径一变记录就指向了不存在的位置。解决先按登记表里的路径列统计出所有涉及目录比对源端和目标端的文件数量再对路径做批量重写。-- 修正栅格登记表里的路径前缀表名与列名以实际登记结构为准 UPDATE raster_catalog SET file_path replace(file_path, /data/gisdata/old/, /data/gisdata/new/) WHERE file_path LIKE /data/gisdata/old/%;执行前先跑一遍同样的条件做SELECT count(*)确认影响行数和预期一致有条件的话开事务执行核对几条样本再提交。路径重写完之后抽三到五个图幅做一次范围框和像素读取的完整验证别只查记录数。5.5 客户端连接报 Operation Failed怎么试都不通现象ksql 能连上ArcCatalog 建连接一直失败报错信息很短看不出原因。原因三类。实例地址没带端口客户端按默认端口连超时后报这个错授权文件不是*.ecp格式建库时授权校验不通过库没有「启动地理数据库」客户端不认。解决实例写成主机,端口的格式端口不是默认值时必须显式带换用正确的 ecp 授权文件先看扩展名再看内容头源库和目标库都执行一次「启动地理数据库」。排查顺序建议是先 ksql 探活、再检查实例格式、最后看授权和启动状态从底层往上排比在客户端里反复试快得多。6. 迁移验收的三类对账 SQL行数、几何有效性、SRID 一致性验收这一步最忌讳只看「任务状态完成」。我一般跑三类对账行数与空几何、几何有效性与范围框、SRID 一致性。前两类合成一条 SQL 就能出结果逐图层拼UNION ALL把关键图层全覆盖。-- 逐图层对账行数、空几何、非法几何、范围框 SELECT roads AS layer, count(*) AS n, count(*) FILTER (WHERE geom IS NULL) AS null_geom, count(*) FILTER (WHERE ST_IsValid(geom) false) AS bad_geom, ST_Extent(geom) AS bbox FROM roads UNION ALL SELECT poi, count(*), count(*) FILTER (WHERE geom IS NULL), count(*) FILTER (WHERE ST_IsValid(geom) false), ST_Extent(geom) FROM poi;null_geom为 0 说明几何没在迁移中丢失bad_geom非 0 就得逐个查多半是源端本来就有自相交的面迁移前就该清洗bbox要和源端导出范围框比对偏差超过容差通常意味着 SRID 配错了——图形看着在位置整体偏移这种错误只有范围框比对能第一时间发现。第三类对账查 SRID拿geometry_columns里的 srid 逐表和源端 EPSG 对照4490 和 4326 混用是重灾区两者在地图上的差别肉眼几乎看不出来但面积计算和叠加分析全错。抽样叠加别省。抽二十个要素导成 shp在 QGIS 里和源库导出的旧数据叠一起看顺便比几个面的面积和线的长度误差在容差内才算过。那次凌晨的故障之后我给自己定了条死规矩每次迁移注册、对账、抽样三步强制走完中间任何一步不做完不进下一步也不接受「先上线后补」的说法。省下来的那半小时后面要用两个通宵还。希望帮到你。本文还有配套的精品资源点击获取