ST_Contains不能直接用于普通JOIN，因要求两参数均为GEOMETRY类型；需先用ST_Point(d.lng,d.lat)和ST_GeomFromText(f.wkt,4326)转换坐标，并对表达式建GIST索引以避免全表扫描。
ST_Contains 为什么不能直接用在普通 JOIN 条件里？
因为 ST_Contains 是 PostGIS 的空间函数，它要求两个参数都必须是 GEOMETRY 类型（且第一个是多边形/面，第二个是点），而原始数据表里坐标通常是分开的 lat/lng 字段或字符串，没经过空间类型转换就调用 ST_Contains 会报错：function st_contains(unknown, unknown) does not exist。
实操要点：
- 必须先用
ST_Point(lng, lat)把经纬度转成点（注意：PostGIS 的ST_Point参数顺序是longitude, latitude，反直觉） - 围栏字段必须是
POLYGON或MULTIPOLYGON类型，如果是 WKT 字符串（如'POLYGON((...))'），得用ST_GeomFromText(wkt_col, 4326)转换并指定 SRID - 两张表 JOIN 前，建议对围栏字段加
GIST空间索引，否则ST_Contains全表扫描极慢
如何写一个能跑通的空间 JOIN 查询？
假设你有两张表：devices（含 id, lat, lng）和 fences（含 fid, wkt，存的是 WKT 格式围栏）。正确写法如下：
SELECT d.id, f.fid
FROM devices d
JOIN fences f
ON ST_Contains(
ST_GeomFromText(f.wkt, 4326),
ST_Point(d.lng, d.lat)
);
关键细节：
-
ST_GeomFromText必须显式传入 SRID（4326是 WGS84 经纬度标准），否则ST_Contains可能因坐标系不匹配返回空结果 - 点构造用
ST_Point(d.lng, d.lat)，不是ST_Point(d.lat, d.lng)——输反了坐标顺序会导致点落在非洲中部 - 如果围栏表中
wkt字段有非法格式（比如少括号、坐标数为奇数），ST_GeomFromText会返回NULL，整行被 JOIN 过滤掉，建议先用WHERE ST_IsValid(ST_GeomFromText(wkt, 4326))预筛
性能差得离谱？检查这三件事
即使语法全对，10 万设备 + 1000 个围栏也可能跑几分钟。瓶颈通常不在函数本身，而在执行计划是否用了空间索引。
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
确认和修复步骤：
- 运行
EXPLAIN ANALYZE，看是否出现Index Scan using fences_gist_idx on fences；如果没有，说明索引没生效或没建 - 建空间索引语句必须是：
CREATE INDEX CONCURRENTLY ON fences USING GIST (ST_GeomFromText(wkt, 4326));——不能对原始wkt字段建，得对表达式建（PostgreSQL 表达式索引） - 如果围栏数量极少（ST_Contains，避免数据库复杂 JOIN 开销
MySQL 用户别硬套 ST_Contains
MySQL 5.7+ 虽然也支持 ST_Contains，但行为差异大：它要求围栏必须是 POLYGON 类型字段（不接受 WKT 字符串直接传入），且点必须用 POINT(lng lat) 构造（注意空格分隔，不是逗号），而且不支持在 JOIN ON 里用函数索引——意味着无法加速。
更现实的做法：
- 把围栏导入为 MySQL 的
GEOMETRY字段（用ST_GeomFromText插入时转换一次） - 设备点仍需用
POINT(devices.lng, devices.lat)构造（注意参数顺序和 PostGIS 一致） - 务必给围栏字段加
SPATIAL索引：ALTER TABLE fences ADD SPATIAL INDEX(fence_geom);
PostGIS 和 MySQL Spatial 对同一组坐标做 ST_Contains 判断，结果可能不一致——前者严格按球面几何，后者按平面欧氏距离，高纬度地区偏差可达数百米。
