ST_Contains 返回 NULL 主因是点与多边形 SRID 不匹配；返回 0 可能因多边形 WKT 格式错误（如环方向或未闭合）；需确保 SRID 一致、WKT 合法、坐标顺序正确（经度在前）、并建立空间索引以提升性能。
ST_Contains 为什么返回 NULL 而不是 TRUE/FALSE
直接用 ST_Contains 判断点是否在多边形内，最常遇到的问题是结果为 NULL，而不是预期的 1 或 0。这通常不是语法错误，而是空间参考系统（SRID）不匹配导致的——MySQL 要求点和多边形必须使用**相同的 SRID**，否则函数拒绝计算并返回 NULL。
实操建议：
- 建表时显式指定 SRID，例如
POINT SRID 4326；插入数据时也带 SRID，如ST_PointFromText('POINT(116.4 39.9)', 4326) - 检查现有字段 SRID：执行
SELECT ST_SRID(your_polygon_col) FROM your_table LIMIT 1 - 临时修复：用
ST_SRID()强制统一，例如ST_Contains(ST_SRID(polygon, 4326), ST_SRID(point, 4326))（但注意：这会丢失索引优化能力）
多边形 WKT 格式写错会导致 ST_Contains 永远返回 0
MySQL 对多边形的 WKT（Well-Known Text）格式非常严格：外环必须按逆时针顺序定义，内环（洞）必须顺时针；且首尾坐标必须完全闭合（即第一个点 = 最后一个点）。哪怕只差一个坐标小数位、或少写一次起始点，ST_Contains 就会静默返回 0（而非报错），让人误以为“点不在里面”。
实操建议：
- 用
ST_IsValid()验证多边形：如果返回0，说明 WKT 不合法，需修正 - 用
ST_AsText()查看实际存入的值，确认是否被 MySQL 自动截断或转换 - 生成标准 WKT 推荐用 GIS 工具导出（如 QGIS → “复制为 WKT”），避免手写；若手写，务必用在线验证器（如 wellknown.org）校验
用 Spatial Index 加速 ST_Contains 查询
没加空间索引时，ST_Contains(poly_col, point_val) 是全表扫描，10 万条多边形记录可能耗时数秒；加上空间索引后，可降到毫秒级。但要注意：MySQL 的空间索引（R-tree）**只加速 MBR（最小边界矩形）预筛选**，真正调用 ST_Contains 做精确判断仍需逐个计算。
实操建议：
- 建空间索引：确保列类型是
POLYGON或MULTIPOLYGON，然后执行ALTER TABLE t ADD SPATIAL INDEX idx_poly (poly_col) - 查询时必须让优化器能用上索引：WHERE 条件中，
ST_Contains的第一个参数要是字段名（不能是表达式），第二个参数要是常量或参数化值，例如WHERE ST_Contains(poly_col, ST_PointFromText('POINT(116.4 39.9)', 4326)) - 用
EXPLAIN确认是否命中索引：输出中key列应显示索引名，Extra不含Using where（表示已用索引过滤掉大部分行）
点坐标顺序搞反（经度/纬度 vs X/Y）引发的定位漂移
MySQL 的 POINT 类型内部存储是 (x, y)，但地理场景中常把经度当 x、纬度当 y。如果原始数据是 lat, lon（如百度地图 API 返回），却直接写成 POINT(lat lon)，会导致点落在完全错误的位置，ST_Contains 结果自然不可信。
实操建议：
- 统一约定：所有地理坐标入库前转为
POINT(longitude latitude)（即POINT(x y)） - 批量转换可用 SQL：例如
UPDATE t SET geo_point = ST_PointFromText(CONCAT('POINT(', lon, ' ', lat, ')'), 4326) - 前端传参时明确字段命名，如
lng和lat，避免用模糊的x/y
真正难的不是写对那行 ST_Contains，而是确保整条链路——坐标来源、WKT 构造、SRID 设置、索引策略——全部对齐。漏掉任意一环，结果都可能看似合理，实则错得离谱。
