MySQL 8.0 对空间数据类型强化了SRID强制性、函数返回类型严格性、几何校验准确性及索引语义一致性，修复5.7中宽松导致的安全与精度问题，升级需重点处理SRID声明、驱动兼容与备份还原逻辑。
GEOMETRY、POINT、POLYGON 等）支持上的差异，不是“能不能用”的问题，而是“能不能高效、安全、标准地用”的问题。8.0 并没有新增空间类型，但重构了底层实现，修复了多个长期存在的语义和行为缺陷。
空间函数返回值类型在 8.0 中更严格
MySQL 5.7 对很多空间函数的返回类型处理宽松甚至错误，比如 ST_Intersection() 在相交为空时可能返回 NULL 或非法 GEOMETRYCOLLECTION，而 8.0 统一按 OpenGIS 标准返回 GEOMETRY 类型（含 EMPTY 实例），且类型检查更严：
-
ST_IsValid()在 5.7 中对某些自相交POLYGON可能误判为1；8.0 使用增强版 GEOS 库，校验更准 -
ST_Distance()在 5.7 中默认使用平面欧氏距离，且不校验 SRID 一致性；8.0 强制要求输入几何体 SRID 匹配，否则报错ER_SRS_NOT_FOUND或ER_SRID_MISMATCH - 使用
ST_GeomFromText('POINT(0 0)', 4326)时，5.7 可能静默忽略 SRID 或存为 0；8.0 会严格绑定 SRID，并在查询时参与坐标系转换逻辑
SRID 支持从“可选标签”变成“强制元数据”
MySQL 5.7 允许创建无 SRID 的空间列（如 POINT），也允许插入不同 SRID 的值混存，这导致空间索引失效、距离计算错误却无提示。
MySQL 8.0 要求：所有空间列必须显式声明 SRID（如 POINT SRID 4326），且插入值若 SRID 不匹配会直接报错 ER_SRID_MISMATCH：
- 建表语句
CREATE TABLE t (g POINT)在 5.7 成功，在 8.0 报错：ERROR 3641 (HY000): A non-empty SRID value is required for column 'g'. - 必须写成
CREATE TABLE t (g POINT SRID 4326)才能通过 - 这意味着旧应用若未管理 SRID，升级后空间字段写入会批量失败，不能只靠迁移脚本自动修复
空间索引行为差异：R-tree 实现升级，但语法兼容性有坑
两者都用 R-tree，但 8.0 使用重写的 SPATIAL 索引引擎，支持更大维度和更精确的 MBR 计算。不过，这个升级带来一个隐蔽陷阱：
- 5.7 中
ALTER TABLE t ADD SPATIAL INDEX(g)对POINT列有效；8.0 同样支持，但若该列未声明 SRID（见上条），命令会失败而非静默忽略 - 8.0 的空间索引在
WHERE ST_Within(p, geom)类查询中命中率更高，但前提是所有几何体都有合法 SRID 且已 ANALYZE TABLE 更新统计信息 - 注意：8.0 不再支持对
GEOMETRY列使用前缀索引（如g(100)），5.7 虽允许但实际无效；8.0 直接拒绝该语法，报错ER_NOT_SUPPORTED_YET
升级时最易被忽略的实操点
空间功能升级不是改个版本号就能跑通的事。真正卡住人的往往不是语法，而是隐式假设的崩塌：
- 备份还原后，5.7 导出的
POINT值（无 SRID）在 8.0 导入时会被赋予默认 SRID 0，后续所有ST_Distance()都按平面坐标算——结果完全错误，且无警告 -
my.cnf中若仍启用skip-grant-tables，8.0 会拒绝启动（因数据字典依赖权限系统），导致空间表元数据不可读 - 客户端驱动必须支持 MySQL 8.0 的新协议；老版
mysql-connector-java 5.1.x读取带 SRID 的POINT字段会抛SQLException，需升到 8.0+ 驱动
