根本原因是navicat默认以文本方式同步空间字段，未自动调用st_geomfromtext()等函数包裹wkt值，导致插入非法字符串而报error 1416；必须手动在字段映射中启用use expression并填写st_geomfromtext(, srid)或改用mysqldump命令行导入。
Navicat 同步含空间地理数据（POINT、POLYGON、GEOMETRY 等）的表时失败，根本原因不是它不支持空间类型，而是它默认用文本方式序列化/反序列化这些值，而 MySQL 的空间函数（如 ST_AsText()、ST_GeomFromText()）未被自动调用，导致 INSERT 语句传入非法字符串或二进制 blob，触发 ERROR 1416 (22003): Cannot get geometry object from data you send to the GEOMETRY field 或类似报错。
同步时 ST_AsText 和 ST_GeomFromText 没被自动包裹
Navicat 不会为 GEOMETRY 列自动生成带空间函数的 SQL。例如源库某行 location 是 POINT(116.4 39.9)，Navicat 默认生成：
INSERT INTO places VALUES (1, 'Beijing', 'POINT(116.4 39.9)');
但目标库期望的是：
INSERT INTO places VALUES (1, 'Beijing', ST_GeomFromText('POINT(116.4 39.9)', 4326));
解决方法只有两种：
- 在 Navicat 同步向导 Step 2 的 Field Mapping 中，对每个空间字段手动勾选 Use expression，然后填入
ST_GeomFromText(<source_field>, 4326)</source_field>（注意替换<source_field></source_field>为实际字段名，SRID 根据业务设为 4326 或 0） - 改用导出 SQL 脚本方式：勾选 Generate synchronization SQL script → 手动打开 .sql 文件 → 全局替换所有
INSERT INTO `table` VALUES (为INSERT INTO `table` SELECT+ 对应ST_GeomFromText()表达式（需逐字段写）
目标库没启用 spatial index 或字段类型不匹配
即使插入成功，后续查询可能报错或性能极差。常见现象：
- 同步后目标表字段类型变成
VARBINARY(255)或TEXT，而非原POINT -
SELECT ST_AsText(location)返回NULL，说明值未被正确解析
原因：Navicat 在结构同步阶段不会主动创建空间索引，且若源表是 POINT NOT NULL，目标建表语句可能漏掉 NOT NULL 或 SRID 约束。
必须人工干预：
- 同步前确认目标库已启用 spatial extension（MySQL 5.7+ 默认开启，老版本需检查
SHOW VARIABLES LIKE 'have_geometry'） - 同步完成后立刻执行：
ALTER TABLE places MODIFY location POINT NOT NULL SRID 4326; - 补空间索引：
CREATE SPATIAL INDEX idx_location ON places(location);
坐标系（SRID）不一致导致同步后数据偏移
源库用 WGS84（SRID 4326），目标库误设为 0 或其他投影坐标系，会导致经纬度数值被错误解释，地图上位置漂移数百公里。
验证方式：连上目标库执行
SELECT ST_SRID(location), ST_AsText(location) FROM places LIMIT 1;
若返回 0 但你期望是 4326，说明同步过程丢失了 SRID 定义。
修复路径：
- 结构同步时，在 Navicat 的 Options → Advanced 中取消勾选 Ignore SRID（该选项默认关闭，但某些旧版本或 profile 可能误开）
- 若已同步完，用
ST_Transform()重设（MySQL 8.0.3+）：UPDATE places SET location = ST_Transform(location, 4326) WHERE ST_SRID(location) = 0; - 更稳妥做法：先导出源表 DDL（
SHOW CREATE TABLE places），复制含SRID 4326的建表语句，在目标库手动重建表并重同步
最易被忽略的一点：Navicat 对 GEOMETRYCOLLECTION 和 MULTILINESTRING 这类复合类型支持极弱，几乎必然失败；遇到这类表，放弃图形化同步，直接用 mysqldump --hex-blob + mysql 命令行导入才是唯一可靠路径。
