MySQL空间索引仅对ST_Contains、ST_Within等特定函数有效，ST_Distance不走索引，ST_Intersects需配合MBR判断；须确保参数顺序正确、SRID显式声明、几何列非NULL且类型匹配，否则索引失效。
MySQL 空间索引为什么没生效？ST_Contains 和 ST_Within 用错就白建
空间索引（SPATIAL）在 MySQL 中只对特定函数有效，不是所有几何运算都能走索引。最常见误区是用 ST_Distance 或 ST_Intersects 做主过滤条件——前者完全不走索引，后者虽支持但需配合 MBR 前置判断才真正高效。
实操建议：
-
WHERE ST_Contains(poly_col, point_col)可走SPATIAL索引，但要求poly_col是查询常量或来自小结果集；若反过来写成ST_Contains(point_col, poly_col)，语法错误且报ER_NON_GEOMETRY_COLUMN - 用
EXPLAIN看执行计划时，key列必须显示你的空间索引名，且type为range或ref；若仍是ALL，大概率是函数用反了或字段顺序错了 - MySQL 5.7+ 对
ST_Within支持更好，语义等价于ST_Contains但参数顺序更符合直觉：ST_Within(point_col, poly_col)—— 这个写法更容易命中索引
建空间索引前必须做这三件事：坐标系、数据类型、NULL 值
空间索引对数据质量极度敏感。一个 NULL 几何值、一个 WGS84 坐标存进 POINT 却没设 SRID，都可能导致索引失效甚至查询崩溃。
实操建议：
- 显式声明
SRID：建表时用POINT SRID 4326，插入时用ST_GeomFromText('POINT(116.3 39.9)', 4326)；不带 SRID 的几何值无法参与某些优化路径 - 禁止在空间列上存
NULL：ALTER TABLE t MODIFY geom POINT NOT NULL SRID 4326，否则索引会跳过这些行，且ST_Contains遇到 NULL 输入直接返回 NULL，逻辑难追踪 - 确保列类型与函数匹配：比如用
POLYGON存面数据，就别拿ST_PointOnSurface去查点——它返回点，但索引建在面列上，无法加速
ST_Distance 排序慢？先用 ST_Distance_Sphere + 范围剪枝
直接 ORDER BY ST_Distance(geom, @p) 必全表扫描，因为距离计算无法下推到索引。正确做法是“先圈范围，再算精距”。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
- 用
ST_Distance_Sphere做粗筛：先加WHERE ST_Distance_Sphere(geom, @p) （单位米），这个条件虽不走空间索引，但能大幅减少排序数据量 - 再在子查询里用
ST_Distance精排：SELECT *, ST_Distance(geom, @p) d FROM (...) t ORDER BY d LIMIT 10，避免大结果集排序 - 如果业务允许误差，用
ST_Distance替代ST_Distance_Sphere（平面距离），性能高 3–5 倍，但仅适用于小范围（如城市内）
MySQL 8.0+ 的 geospatial index 和旧版 SPATIAL 有什么实际区别？
MySQL 8.0 把空间索引底层换成了 R-tree with packing，不再依赖 MyISAM 引擎，InnoDB 原生支持，但行为变化不小——尤其是对多边形边界和自相交的容忍度。
实操建议：
- 8.0+ 中
ST_IsValid(geom)返回0的数据，建空间索引会失败并报ER_INVALID_GEOJSON；而 5.7 可能静默接受但查询结果异常 - 批量导入前务必运行
UPDATE t SET geom = ST_MakeValid(geom) WHERE NOT ST_IsValid(geom)，否则索引可能建成功但部分查询漏数据 - 8.0+ 的
ST_Contains对“点恰在多边形边界上”的判定更严格，若业务依赖边界包含，需改用ST_Covers并测试兼容性
空间索引不是开箱即用的加速器，它是把双刃剑：建错、用错、数据脏，都会让查询比全表扫描还慢。最容易被忽略的是 SRID 一致性——同一张表里混用 4326 和 3857，或者函数里硬编码坐标却不指定 SRID，这种问题不会报错，但索引永远不生效。
