简介《人大金仓-KingbaseES GIS数据迁移方案》V8.6面向数据库管理员、GIS开发人员及迁移实施团队聚焦地理空间数据从ArcGIS、GeoScene、SuperMap等平台向KingbaseES迁移的实际需求提供分平台的方法论与操作参考。压缩包内含1个PDF文件约2.76MB以单文档形式组织完整内容适合离线查阅和项目归档。文档从KingbaseES的GIS能力及其与空间数据的关系讲起随后按ArcGIS/GeoScene、SuperMap和第三方通用格式三条路径展开既覆盖KDTS工具的数据抽取、转换、加载流程也说明借助GIS软件自身导出导入功能的做法并在各章给出迁移结果验证与FAQ。读者可据此掌握源库与目标库连接配置、迁移表字段选择、数据完整性与准确性核对等关键环节减少跨平台迁移中的试错成本。目前已有137人学习。1. 从空间库搬到 KingbaseES V8.6为什么普通表的迁移套路在这里会失灵一次常规业务库迁移导出、建库、导入、核对行数半天收工。但把同样一套流程套到 GIS 数据上十有八九会在第三天卡住表建好了数据也进去了ST_Area算出来的面积却是 0.003或者外包框直接跑到南极洲。问题不在数据本身而在几何列带了三样普通列没有的东西——类型修饰、坐标系标识和空间索引。KingbaseES V8.6 的内核与 PostgreSQL 高度兼容这既是好消息也是陷阱语法看着眼熟于是很多人默认直接 dump 过去就行结果在扩展安装、SRID 校验、WKB 精度上接连翻车。这篇讲的是一套可复现的 KingbaseES GIS 数据迁移路径从源端家底盘点开始到路径选型、几何落地、索引重建再到验收口径和五类典型故障的排查手法。适合手里有几十 GB 到几 TB 空间数据、准备做国产化替换的开发者也适合已经迁完一轮但对不上数、想回头找原因的人。2. 迁移前的家底盘点几何类型、SRID 和扩展能力怎么摸清动手导出之前先把源端和目标端各拍一张X 光片。空间数据迁移里最贵的成本不是传输时间而是迁完才发现坐标系标错、维度丢失、无效几何被静默丢弃。这三类问题都不会报错只会在业务侧以地图上位置偏了三百米的形式冒出来排查成本极高。2.1 用四条 SQL 摸清源库的空间家底先连上源库把空间列的清单拉出来。下面这段在常见的 PostGIS 兼容库上都能跑输出的结果可以直接当迁移清单用。-- 1) 全库空间列清单库名、表名、几何列名、声明类型、SRID、维度 SELECT f_table_schema, f_table_name, f_geometry_column, type, srid, coord_dimension FROM geometry_columns ORDER BY f_table_schema, f_table_name; -- 2) 声明为 Geometry 但实际混装多种类型的情况最容易在目标端建表时翻车 SELECT ST_GeometryType(geom) AS gtype, count(*) AS cnt FROM gis.parcel GROUP BY 1 ORDER BY 2 DESC; -- 3) SRID 缺失或为 0 的记录这些是后续坐标轴错乱的源头 SELECT count(*) AS srid_zero_cnt FROM gis.parcel WHERE ST_SRID(geom) 0 OR geom IS NULL; -- 4) 无效几何自相交、环未闭合、坐标重复点 SELECT count(*) AS invalid_cnt FROM gis.parcel WHERE NOT ST_IsValid(geom);第一条查的是元数据视图geometry_columns字段含义分别是f_geometry_column是几何列名type是建表时声明的类型可能是笼统的GEOMETRYsrid是坐标系编码coord_dimension是维度2 表示 XY3 表示 XYZ 或 XYM。第二条用ST_GeometryType看实际存储的类型分布如果一张声明为GEOMETRY的表里同时有ST_Point和ST_Polygon目标端就不能建成带类型修饰的列否则导入会整批失败。第三、四条是为后面的数据清洗做准备ST_SRID(geom) 0的记录必须业务方逐条确认坐标参考机器猜不出来。把结果导出成 CSV 存档这份清单在后面做验收比对时还要用一次。2.2 几何类型与 SRID 的映射表怎么定盘点完之后逐列决定目标端的写法。这一步定错了后面所有 SQL 都是白干。下表是我一般会拿给业务方确认的对照口径。源端声明目标端建议写法需要注意的点geometry(Point,4326)geometry(Point,4326)直接对应WGS84 下轴序是经度在前别手工调换geometry(Geometry,0)先清洗 SRID再定geometry(Geometry,4490)SRID 为 0 必须业务确认不能默认按 4490 处理geometry(PointZ,4490)geometry(PointZ,4490)三维数据丢 Z 是最隐蔽的坑建表时不带 Z 会被静默降维geography(Point,4326)geometry(Point,4326) 应用层算距离部分版本对 geography 支持有限落地成 geometry 更稳圆弧、曲线类型先用ST_CurveToLine降级为线串直接导入大概率报类型不支持声明MultiPolygon实存Polygon统一升为MultiPolygon用ST_Multi批量升级避免逐条补SRID 的选择上国内业务常见的是 CGCS2000 系列地理坐标 EPSG:4490投影坐标按高斯-克吕格分带。如果源端用的是 WGS844326而业务要求出图对齐国内底图就需要在迁移阶段一次性做ST_Transform而不是留到查询时每条 SQL 里转——后者会让空间索引彻底失效。提示SRID 映射表一定要落到文档里并让业务方签字确认口头说应该都是 4490是迁移事故的高发起点。2.3 目标端空间扩展的确认与初始化KingbaseES 的空间能力通过扩展提供装没装、叫什么名字不同交付介质和版本会有差异别凭记忆写。先连上去看一眼。# 连接目标库端口以实际部署为准KingbaseES 常见默认端口是 54321 ksql -h 10.0.0.11 -p 54321 -U system -d gisdb-- 已安装扩展 \dx -- 可用扩展清单视图名在不同版本可能是 sys_available_extensions 或 pg_available_extensions SELECT name, default_version, installed_version FROM sys_available_extensions WHERE name ILIKE %gis% OR name ILIKE %spatial%; -- 安装空间扩展扩展名以上一步查询结果为准 CREATE EXTENSION postgis; -- 验证能返回版本号就说明函数库已就位 SELECT postgis_version(), postgis_full_version();\dx是元命令列出当前库已安装的扩展第二条查的是可用扩展清单installed_version为空表示有安装包但没启用。CREATE EXTENSION如果报could not open extension control file说明空间组件压根没随安装介质部署这时候不是改 SQL 能解决的得回到安装环节补装 GIS 组件。扩展装完立刻做一次冒烟验证别等到导入几千万行才发现函数缺失SELECT ST_AsText(ST_GeomFromText(POINT(116.39 39.9), 4490)) AS pt, ST_SRID(ST_GeomFromText(POINT(116.39 39.9), 4490)) AS srid, round(ST_Distance(ST_GeomFromText(POINT(116.39 39.9), 4490), ST_GeomFromText(POINT(116.40 39.9), 4490))::numeric, 6) AS deg_dist;这段同时验证了三件事WKT 解析可用、SRID 能正确写入、距离函数能跑通。注意最后算出来的deg_dist单位是度不是米这是 4490 地理坐标系的固有特性后面算面积时会再遇到。3. 三条迁移路径怎么选逻辑导出、文件中转与分批搬运家底摸清之后才谈路径。空间数据的迁移路径比普通表少很多因为几何列是二进制大对象很多看起来能走的通道实际上会把几何打散成文本再拼回来精度和 SRID 全丢。我一般只在三条路里选按数据量分界几十 GB 以内走逻辑导出异构源或文件源走 GDAL 中转TB 级超大表单表走分批搬运。3.1 整库逻辑导出sys_dump 与 sys_restore 的可用边界先说清楚一条红线数据库的物理备份文件不能跨内核版本直接拿来用。空间库迁移必须走逻辑导出也就是把数据导成 SQL 文本或自定义格式再在目标端重放。# 源端导出自定义格式 压缩排除 spatial_ref_sys 避免与目标端冲突 sys_dump -h 10.0.0.20 -p 5432 -U gis_user -d gisdb \ -Fc -Z 6 \ --no-owner --no-privileges \ -T spatial_ref_sys \ -f /data/migrate/gisdb.dump参数逐个说-Fc指定自定义格式custom这是唯一支持并行恢复和选择性恢复的格式纯文本的-Fp在大库上会非常慢-Z 6是压缩级别0 到 9空间数据本身压缩率一般6 是比较平衡的值再往上 CPU 开销不划算--no-owner --no-privileges去掉属主和权限语句否则目标端没有同名角色会一路报错-T spatial_ref_sys排除坐标系字典表因为目标端扩展安装时已经写入了一份覆盖会导致主键冲突。恢复到目标端# 先只恢复表结构验证建表语句能否通过 sys_restore -h 10.0.0.11 -p 54321 -U system -d gisdb \ --no-owner --no-privileges \ --schema-only \ /data/migrate/gisdb.dump # 结构无误后再并行恢复数据 sys_restore -h 10.0.0.11 -p 54321 -U system -d gisdb \ --no-owner --no-privileges \ -j 4 \ /data/migrate/gisdb.dump--schema-only只导结构这一步是后悔药结构有问题就地改不用等数据全灌进去再回滚。-j 4是并行度只对自定义格式生效一般设成 CPU 核数的一半到相等设太高反而因为锁竞争变慢。注意工具名在不同交付版本里可能是sys_dump/sys_restore也可能保留pg_dump/pg_restore兼容入口用--help确认后再写进脚本别把命令硬编码到一个不存在的二进制上。如果sys_restore直接报解析错误说明跨内核的归档格式不兼容。这时候退回纯 SQL 文本路线sys_dump -Fp导出后用ksql -f重放速度慢但兼容性好。我曾经在一个跨大版本的项目上就是靠这条慢路子把 40 GB 数据搬完的血泪经验是先用一张一万行的小表试通整条链路再动全量。3.2 文件中转Shapefile 和 GeoJSON 走 ogr2ogr源端不是数据库而是 Shapefile、GeoJSON、FileGDB 时GDAL 的ogr2ogr是最省事的通道。它直接写目标库几何以 WKB 写入不会经过文本拼装。ogr2ogr -f PostgreSQL \ PG:host10.0.0.11 port54321 dbnamegisdb usersystem password****** \ /data/shp/road.shp \ -nln gis.road \ -nlt PROMOTE_TO_MULTI \ -lco GEOMETRY_NAMEgeom \ -lco FIDgid \ -lco SPATIAL_INDEXGIST \ -lco ENCODINGUTF-8 \ -t_srs EPSG:4490 \ -progress-f PostgreSQL是输出驱动KingbaseES 协议层兼容多数场景可以直接用-nln指定目标表的 schema.table 全名-nlt PROMOTE_TO_MULTI把单几何提升为多几何这是 Shapefile 迁移的必备参数——Shapefile 一个图层里可能混着 Polygon 和 MultiPolygon不升维的话建表类型会打架-lco GEOMETRY_NAMEgeom指定几何列名-lco FIDgid指定主键列名-lco SPATIAL_INDEXGIST让驱动建表时顺手建 GiST 索引小数据量方便大数据量建议改成NONE导完再手工建-lco ENCODINGUTF-8处理属性表编码-t_srs做坐标转换。属性乱码是这条路线的经典翻车点。老的 Shapefile 的 DBF 部分常用 GBK 编码ENCODINGUTF-8只声明目标端用什么编码源端编码要用-oo ENCODINGGBK指定。两个参数搞混导入的中文地名就是一串问号。3.3 大表分批搬运按主键区间切片的脚本写法单表过亿行时一次性导出会遇到两个问题事务日志暴涨、失败重来成本极高。分批搬运的核心是让每一批都是独立事务断了从断点续。# batch_move.py按主键区间分批搬运每批独立提交支持断点续传 import psycopg2 SRC host10.0.0.20 port5432 dbnamegisdb usergis_user password****** DST host10.0.0.11 port54321 dbnamegisdb usersystem password****** BATCH 50000 # 每批行数按单行几何大小调整几何越大批次越小 def move_table(table: str, geom_col: str, srid: int): src psycopg2.connect(SRC) dst psycopg2.connect(DST) cur_s src.cursor(namestream) # 命名游标服务端流式读取避免一次性拉满内存 cur_s.itersize BATCH cur_s.execute(fSELECT gid, name, ST_AsBinary({geom_col}) FROM {table} ORDER BY gid) cur_d dst.cursor() n 0 while True: rows cur_s.fetchmany(BATCH) if not rows: break # 目标端用 ST_GeomFromWKB 还原SRID 显式传入不依赖源端元数据 cur_d.executemany( INSERT INTO gis.%s (gid, name, geom) VALUES (%%s, %%s, ST_GeomFromWKB(%%s, %d)) ON CONFLICT (gid) DO NOTHING % (table, srid), rows, ) dst.commit() # 每批独立提交失败只回滚当前批 n len(rows) print(f{table}: {n} rows committed) src.close(); dst.close() if __name__ __main__: move_table(road, geom, 4490)关键点在三个地方。cursor(namestream)建的是服务端游标itersize控制每次网络往返拉多少行这是避免客户端内存被打爆的关键ST_AsBinary把几何序列化成 WKB二进制通道不会丢精度也不会被字符集干扰ST_GeomFromWKB(%, srid)显式传 SRID不依赖源端geometry_columns的元数据因为源端标错 SRID 的情况太常见了。ON CONFLICT (gid) DO NOTHING让脚本可以重复执行中断后从断点继续而不用清表重来。提示驱动层能连通不代表函数全兼容。跑全量之前先用SELECT postgis_version()在目标端确认函数库再拿 1000 行做一次端到端验证。4. 几何字段落地建表、批量写入与 GiST 索引的三个必调参数数据能过去了接下来决定它存得好不好。同一批几何建表方式不同查询性能能差出一个数量级写入方式不同导入耗时能差三倍。这一章的三节分别对应建表、写入、索引每一节都有一个必须调的参数。4.1 建表时几何列的 typmod 到底该不该加CREATE SCHEMA IF NOT EXISTS gis; CREATE TABLE gis.road ( gid bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, name varchar(128), grade smallint, geom geometry(MultiLineString, 4490) ); COMMENT ON COLUMN gis.road.geom IS CGCS2000 地理坐标MultiLineString单位度;geometry(MultiLineString, 4490)里的括号部分是类型修饰符typmod它带来两个强制约束插入的几何类型必须是 MultiLineStringSRID 必须是 4490。好处是脏数据在写入时就被拦下来坏处是导入性能有损耗——每条 INSERT 都要做一次类型和 SRID 校验而且源端一旦有单几何混进来就整批失败。我的做法是分阶段导入阶段建不带修饰的geometry列让数据先进来导完做一次全量校验把不合规的记录挑出来清洗最后用ALTER TABLE ... ALTER COLUMN geom TYPE geometry(MultiLineString, 4490) USING ST_Multi(geom)补上约束。这样导入快约束也不缺。如果坚持一开始就带修饰务必把源端的ST_Multi提升提前做掉-- 不带修饰的过渡表先接住所有几何 CREATE TABLE gis.road_stage ( gid bigint, name varchar(128), grade smallint, geom geometry );不带修饰的列不校验类型和 SRID等于把校验责任交给了后续步骤所以过渡表千万不要直接对外提供查询。4.2 批量写入COPY 加 WKB 十六进制是吞吐最高的组合单条 INSERT 写空间数据是最慢的方式因为每条都要走一次解析、一次索引维护。生产上我一般用COPY把数据先落到文本暂存表再用一条INSERT ... SELECT做几何还原一次成型。-- 暂存表几何先以 WKB 的十六进制文本形式落地 CREATE TEMP TABLE road_raw ( gid bigint, name varchar(128), grade smallint, geom_hex text ); -- 从 CSV 高速灌入全程不碰几何函数速度最快 \copy road_raw FROM /data/migrate/road.csv WITH (FORMAT csv, HEADER true, ENCODING UTF8) -- 一次性还原几何并写入正式表 INSERT INTO gis.road (gid, name, grade, geom) SELECT gid, name, grade, ST_Multi(ST_GeomFromWKB(decode(geom_hex, hex), 4490)) FROM road_raw WHERE geom_hex IS NOT NULL AND geom_hex ; ANALYZE gis.road;decode(geom_hex, hex)把十六进制字符串还原成 byteaST_GeomFromWKB再把它解析成几何对象第二个参数 4490 是 SRID。外面套一层ST_Multi是为了应对源端混着单几何的情况。WHERE geom_hex IS NOT NULL过滤空值避免ST_GeomFromWKB拿到 NULL 后几何列变成空但行还在这类半条记录最难查。批量大小上\copy单文件建议控制在 1 到 2 GB再大就切成多个文件顺序灌。中间不要commit太频繁一个文件一个事务事务日志压力可控。4.3 GiST 索引建的时间点和两个参数决定成败空间查询不走 GiST 索引等于全表扫描。但索引建得太早导入过程中每插一行都要维护一次索引树导入时间可能翻两三倍。正确顺序是清空表 → 灌数据 → 建索引 →ANALYZE。-- 大批量导入期间临时放大维护内存减少外部排序 SET maintenance_work_mem 2GB; SET max_parallel_maintenance_workers 4; -- 建 GiST 索引几何列直接建不要包函数 CREATE INDEX idx_road_geom ON gis.road USING gist (geom); -- 常用按投影坐标范围查的场景可以补一个表达式索引代价是写入变慢 CREATE INDEX idx_road_geom_3857 ON gis.road USING gist (ST_Transform(geom, 3857)); -- 建完必须收集统计信息否则优化器可能仍然选全表扫描 ANALYZE gis.road;maintenance_work_mem是维护类操作建索引、VACUUM可用的内存索引构建阶段调大到 1 到 2 GB 能显著减少磁盘临时文件max_parallel_maintenance_workers控制并行建索引的进程数表越大收益越明显小表反而因为进程启动开销变慢。表达式索引要谨慎。上面那个ST_Transform(geom, 3857)的索引只有查询条件写成完全相同的表达式时才会命中写成ST_Transform(geom, 3856)或者换个 SRID 就完全用不上。而且它会让每次写入都多算一次坐标转换写入性能下降明显。我的习惯是先用单列 GiST 索引扛住大部分场景确有高频固定投影查询再补表达式索引并且用EXPLAIN (ANALYZE, BUFFERS)确认真的命中了再保留。5. 迁移避坑清单五类翻车现场的现象、原因与解法下面这五条都是我在真实迁移里遇到过、并且不止遇到一次的。每条按现象、原因、解决三步写对着排查能省掉大量猜测时间。5.1 面积算出来是 0.0003或者大得离谱现象数据全部导入成功ST_Area(geom)返回 0.0003 这种量级的数字业务方说我们这块地是 3000 平方米。原因几何存的是地理坐标单位是度直接在度上算面积得到的单位是平方度没有任何业务意义。另一种反向情况是 SRID 标成了投影坐标系单位米但实际存的是经纬度算出来的面积会大出十几个数量级。解决先确认ST_SRID(geom)的真实值再决定算法。地理坐标下算面积要么转到等积投影要么转 geography 类型再算-- 地理坐标下算平方米先转 geography 再取面积 SELECT gid, round(ST_Area(geom::geography)::numeric, 2) AS area_m2 FROM gis.parcel LIMIT 10;同时把 SRID 一致性做成约束从根上堵住ALTER TABLE gis.parcel ADD CONSTRAINT parcel_srid_chk CHECK (ST_SRID(geom) 4490);5.2 恢复时报 type geometry does not exist现象sys_restore跑到建表语句就中断报类型不存在但明明已经装过空间扩展。原因两个可能。一是扩展装在了另一个库或者另一个 schema当前search_path找不到二是恢复时的连接用户不是扩展的属主权限不足看不到类型。解决先在目标库确认扩展的实际安装位置再显式设置搜索路径。-- 确认扩展装在哪个 schema SELECT e.extname, n.nspname FROM sys_extension e JOIN sys_namespace n ON e.extnamespace n.oid WHERE e.extname ILIKE %gis% OR e.extname ILIKE %spatial%; -- 恢复会话里显式指定搜索路径 SET search_path TO gis, public, $user;如果扩展压根没装回到 2.3 节补装别在恢复脚本里加CREATE EXTENSION硬扛——权限和依赖顺序都会出问题。5.3 属性表中文全变成问号几何却完好现象地图能正常渲染但道路名称、行政区名全是???。原因源端 Shapefile 的 DBF 部分用 GBK 编码ogr2ogr的-lco ENCODINGUTF-8只声明了目标端编码没有告诉驱动源端是什么编码。解决源端编码用-ooopen option指定和目标端编码分开写ogr2ogr -f PostgreSQL PG:host10.0.0.11 port54321 dbnamegisdb usersystem password****** \ /data/shp/road.shp -nln gis.road \ -oo ENCODINGGBK \ -lco ENCODINGUTF-8 \ -nlt PROMOTE_TO_MULTI-oo是输入侧选项-lco是输出侧选项两者作用对象不同。遇到乱码先看源文件的实际编码别盲目试 UTF-8。5.4 导入越跑越慢最后几乎停滞现象前 100 万行每秒几万条到 500 万行掉到每秒几百条磁盘 IO 打满。原因三个叠加因素。边插边维护 GiST 索引索引树越深插入越慢单个事务太大回滚段和 WAL 持续膨胀批量插入触发 autovacuum和导入抢 IO。解决导入前把索引和非主键约束全部删掉导入期间关掉该表的 autovacuum导完再重建。-- 导入前 ALTER TABLE gis.road SET (autovacuum_enabled false); DROP INDEX IF EXISTS idx_road_geom; -- 导入完成后 ALTER TABLE gis.road SET (autovacuum_enabled true); CREATE INDEX idx_road_geom ON gis.road USING gist (geom); ANALYZE gis.road;另外把单批事务控制在 5 万到 20 万行之间别一个事务干到底。5.5 建了索引却始终不走查询还是全表扫现象GiST 索引明明建了EXPLAIN出来还是 Seq Scan几十秒才出结果。原因查询条件把几何列包在函数里了比如WHERE ST_Transform(geom, 3857) ST_MakeEnvelope(...)索引是建在geom上的包了函数就用不上除非正好建了同表达式的索引。另一个常见原因是统计信息过期优化器低估了选择率。解决把函数挪到常量侧让几何列裸露在条件左边-- 错误写法几何列被函数包裹索引失效 SELECT * FROM gis.road WHERE ST_Transform(geom, 3857) ST_MakeEnvelope(12900000, 4800000, 12950000, 4850000, 3857); -- 正确写法先把查询范围转回存储坐标系几何列保持裸露 SELECT * FROM gis.road WHERE geom ST_Transform(ST_MakeEnvelope(12900000, 4800000, 12950000, 4850000, 3857), 4490);改完之后再ANALYZE一次用EXPLAIN (ANALYZE, BUFFERS)确认出现Bitmap Index Scan on idx_road_geom才算真正修好。6. 验收与灰度切换用一组 SQL 证明迁移真的没丢东西迁移做完最怕的不是报错而是看起来没问题。行数对上了不代表几何对上了几何对上了不代表坐标系对上了。我一般用下面这组口径做验收每一项都有明确的通过标准不靠感觉。验收项核查 SQL 口径通过标准行数一致性SELECT count(*) FROM gis.road;与源端差值在业务允许的过滤范围内且差异逐条可解释几何空值率SELECT count(*) FROM gis.road WHERE geom IS NULL;与源端空值数一致不允许少了几条但没报错外包框SELECT ST_AsText(ST_Extent(geom)) FROM gis.road;与源端外包框的四个角点误差在容差内坐标系一致性SELECT DISTINCT ST_SRID(geom) FROM gis.road;只返回预期的一个 SRID几何有效性SELECT count(*) FROM gis.road WHERE NOT ST_IsValid(geom);无效几何数不高于源端新增的必须修复面积总量转 geography 后sum(ST_Area(geom::geography))与源端总量偏差小于万分之一类型一致性SELECT DISTINCT ST_GeometryType(geom) FROM gis.road;与目标表声明的类型匹配外包框那一条特别值得做它能一次性抓出坐标轴翻转的问题。如果源端外包框的经度范围是 73 到 135目标端变成 -90 到 90 之类的数字就是坐标轴顺序反了用ST_FlipCoordinates批量纠正后再比对。同样的手法可以用来抓整批数据偏移只要对比几个采样点的坐标就能看出来。面积总量比对要注意口径统一两边都在 geography 下算或者两边都转到同一个等积投影下算不要一边算平方度一边算平方米。灰度切换上我的习惯是先切读不切写。用一套只读账号把报表类和地图服务的查询指到新库跑一周对比同一批请求的返回结果和响应时间。这期间源库继续接收写入靠增量脚本把变更同步过去——增量同步按updated_at时间戳拉几何列同样走 WKB 通道。等读侧稳定、验收项全绿再做一次短窗口的停写切换把写入口指过去。最后说个我自己的教训第一次做这类迁移时我图省事跳过了抽样点位比对只看了行数和外包框。结果上线一周后业务反馈某个区的边界线整体偏了大概两百米回头查是那一批数据的 SRID 被标成了相邻带的投影坐标。从那以后我的验收脚本里固定加一条随机抽 20 个要素把ST_AsText(ST_Centroid(geom))的坐标打到日志里和源端逐条对照。这条检查只花两分钟但能拦住九成的坐标系事故。希望帮到你。本文还有配套的精品资源点击获取
设计与优化实战指南)
