MySQL 5.7+严格模式下GIS字段同步报错“BLOB/TEXT column can’t have a default value”，因POINT/POLYGON被归为BLOB变体且禁止DEFAULT；Navicat同步时未处理WKB二进制、SRID及空间函数依赖，导致NULL、乱码或功能失效。

同步含 POINT / POLYGON 字段的表报错 “BLOB/TEXT column can’t have a default value”

这是 mysql 5.7+ 严格模式下的典型拦截，不是 navicat 问题。gis 类型（如 point、polygon、geometry）在 mysql 内部被归类为 blob 或 text 类型变体，而严格模式禁止这类字段设 default 值（哪怕你没显式写，默认值也会被隐式推导为 null 或空，触发校验失败）。

Navicat 同步结构时若检测到源表字段定义含 GIS 类型，会尝试在目标库重建相同 DDL，但一旦目标库开启 STRICT_TRANS_TABLES（MySQL 5.7+ 默认），建表语句中带 DEFAULT 的 GIS 字段就会直接报错中断。

• 先连目标库执行：SELECT @@sql_mode;，确认是否含 STRICT_TRANS_TABLES
• 查源表 DDL：SHOW CREATE TABLE `your_table`;，看 GIS 字段行是否带 DEFAULT（例如 location POINT DEFAULT NULL）
• 临时解决：在同步前对目标库执行 SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION';（仅当前会话生效）
• 长期方案：修改目标库配置文件 my.cnf，移除 STRICT_TRANS_TABLES，重启 MySQL（需 DBA 权限）

同步后 GIS 字段值变成 NULL 或乱码

根本原因是 Navicat 对二进制 GIS 数据的序列化/反序列化支持不完整。它默认把 POINT 当作普通字符串处理，而实际存储是 WKB（Well-Known Binary）格式；若源库用 ST_AsText() 显示，目标库却按原始二进制读取，就必然失真。

尤其当字段类型在源目标库不完全一致时（比如源是 POINT，目标误建为 GEOMETRY 或 TEXT），Navicat 不做类型强校验，直接搬运字节流，结果就是 NULL 或不可解析的二进制垃圾。

• 同步前务必确认源目标表中 GIS 字段类型完全一致：DESCRIBE your_table; 比对 Type 列
• 避免跨引擎同步：MyISAM 表的 GIS 支持弱于 InnoDB，Navicat 可能忽略引擎差异，导致字段丢失
• 不要依赖 Navicat 的「自动类型映射」——进入同步向导 Step 2 的 Field Mapping，手动检查每列类型，禁用自动推导
• 验证同步结果：在目标库执行 SELECT ST_AsText(location) FROM your_table LIMIT 1;，若返回 NULL 或报错 Invalid GIS data provided，说明数据已损坏

“Unknown column type ‘geometry’” 或同步向导卡在解析阶段

这是 Navicat 版本兼容性问题。旧版 Navicat（≤15.0.30）对 MySQL 8.0.24+ 新增的空间参考系统（SRID）支持不全，解析 POINT SRID 4326 这类带 SRID 的定义时会抛出未知类型错误，甚至卡死在「正在解析 SQL」界面。

navicatmysql

Navicat For MySQL

下载

它和数据库连接无关，而是 Navicat 内置的 SQL 解析器无法识别新版 MySQL 的空间语法扩展。

• 升级 Navicat 至 16.1.10 或更高版本（官方 2026 年 3 月起全面支持 SRID 和 GEOMCOLLECTION）
• 降级兼容方案：在源库临时导出无 SRID 的字段，执行 ALTER TABLE t MODIFY location POINT;（去掉 SRID），再同步
• 绕过 Navicat：用原生命令导出 GIS 数据：mysqldump --hex-blob --skip-triggers db_name table_name > gis_data.sql，然后手动导入目标库
• 注意 --hex-blob 参数必须加，否则 WKB 二进制会被截断或转义错误

同步时提示 “Function ‘ST_Distance’ doesn’t exist” 或触发器失效

这不是同步过程出错，而是同步后首次查询 GIS 字段时暴露的问题。Navicat 同步只搬运表结构和数据，不迁移函数、存储过程、触发器等服务端逻辑。如果源表依赖 ST_Distance、ST_Contains 等空间函数做计算列或触发器校验，目标库缺失这些函数（尤其是 MySQL 5.7 默认未启用 spatial extensions），就会在后续操作中报错。

更隐蔽的是：Navicat 结构同步可能跳过函数依赖检查，让你误以为“表建成功了就万事大吉”。

• 同步前在目标库执行：SELECT plugin_name, plugin_status FROM information_schema.plugins WHERE plugin_name LIKE '%spatial%';，确认 spatial_plugin 状态为 ACTIVE
• 检查目标库 MySQL 版本是否支持所需函数（例如 ST_DistanceSphere 仅 MySQL 5.7.6+ 支持）
• 若用到自定义 GIS 函数或触发器，必须单独导出并手动在目标库执行：SHOW CREATE FUNCTION func_name; → 复制 → 目标库执行
• Navicat 的「同步结构」选项里没有「同步函数」开关，这点必须人工补位，不能漏

GIS 数据同步的坑不在“能不能点下一步”，而在“点完之后数据还能不能用”。WKB 字节流、SRID 元数据、空间函数依赖这三者任何一个断链，都会让地理信息彻底失效——而 Navicat 日志通常只报表名和 SQL 错误码，不会告诉你“你的地图坐标已经偏移 300 公里”。