MySQL 8.0升级后SPATIAL索引报错需先修复字段：设NOT NULL、显式SRID（如4326），清理NULL值并统一SRID，再分步DROP/CREATE索引，且应用中ST_Contains参数须带相同SRID。
MySQL升级后SPATIAL索引报错“Unsupported geometry type”
MySQL 5.7 升级到 8.0 后，原有 POINT 字段上的 SPATIAL 索引可能失效，执行 SELECT ... WHERE ST_Contains(...) 时抛出 ER_UNSUPPORTED_GEOMETRY_TYPE。根本原因是 8.0 默认启用严格 SQL 模式 + ST_Contains 对几何对象的 SRID 和类型校验更严，而旧索引未绑定 SRID 或使用了隐式坐标系。
- 检查当前字段定义：
SHOW CREATE TABLE t;，确认geom列是否为POINT类型且无SRID属性（如POINT SRID 0） - 验证索引状态：
SHOW INDEX FROM t WHERE Key_name = 'spatial_idx';，若Comment列显示disabled或Type为BTREE而非SPATIAL，说明索引已降级 - 必须先删除旧索引再重建，直接
ALTER ... ADD SPATIAL INDEX会失败，报错ER_SPATIAL_CANT_HAVE_NULL（因字段允许 NULL）
重建SPATIAL索引前必须清理数据和字段约束
MySQL 8.0 要求参与 SPATIAL 索引的列不能为 NULL，且必须显式声明 SRID。即使原数据全是有效 POINT，只要字段定义含 DEFAULT NULL 或未设 NOT NULL，重建就会中断。
- 先修补字段：执行
ALTER TABLE t MODIFY geom POINT NOT NULL SRID 4326;（推荐用 WGS84，即SRID 4326） - 若存在
NULL值，需提前填充，例如：UPDATE t SET geom = ST_PointFromText('POINT(0 0)', 4326) WHERE geom IS NULL; - 确保所有值都带正确 SRID：运行
SELECT id, ST_SRID(geom) FROM t WHERE ST_SRID(geom) != 4326;，对不一致记录用ST_SetSRID修正
DROP 和 ADD SPATIAL INDEX 必须分两步执行
不能用单条 ALTER TABLE ... DROP INDEX ... ADD SPATIAL INDEX 语句——MySQL 会尝试在旧索引还存在时创建新索引，触发元数据锁冲突或类型校验失败。
- 第一步删索引：
DROP INDEX spatial_idx ON t; - 第二步建索引：
CREATE SPATIAL INDEX spatial_idx ON t (geom);（注意：8.0+ 不再支持USING RTREE，直接省略即可） - 验证是否生效：
EXPLAIN SELECT * FROM t WHERE MBRContains(ST_Envelope(spatial_idx), geom);中key列应显示spatial_idx - 若表数据量大，重建期间会锁表；生产环境建议在低峰期操作，或用
pt-online-schema-change替代
应用层调用ST_Contains时必须传入带SRID的几何参数
索引重建成功不等于查询自动变快。如果应用中仍用 ST_GeomFromText('POINT(x y)') 构造参数，生成的几何对象默认 SRID 0，与索引的 SRID 4326 不匹配，优化器将弃用索引，回退全表扫描。
- 所有输入几何必须显式指定 SRID：
ST_GeomFromText('POINT(116.397 39.909)', 4326) - 避免混用函数：不要用
GeomFromText（旧别名），统一用ST_GeomFromText - 检查执行计划是否真走索引：
EXPLAIN FORMAT=JSON SELECT ...中查看used_key_parts是否包含geom
重建不是简单删再加，关键在字段 SRID 对齐、NULL 约束补全、以及应用侧几何构造的一致性。漏掉任意一环，索引看起来存在，实际查不到。
