postgresql中point类型不支持空间索引和st函数，须用geometry或geography类型并指定srid（如geography(point,4326)），建表时配gist索引，插入用st_setsrid或st_point，查询需确保crs一致。
postgresql 中 point 字段怎么建才支持空间查询
直接用 point 类型（如 point）不能建空间索引，它只是个二维坐标容器，没地理语义，也不带 srid。真正能支撑 st_contains、st_dwithin 这类函数的，是 geometry 或 geography 类型。
实操建议：
- 用
GEOMETRY存平面坐标（比如 Web Mercator 投影下的地图瓦片数据），或GEOGRAPHY存经纬度（WGS84，单位是米，适合真实距离计算） - 建表时显式指定 SRID：
geography(POINT, 4326)，不写默认是 4326，但写出来更安全，避免后续ST_Transform出错 - 插入数据必须用
ST_Point或ST_SetSRID构造，不能直接写(116.3, 39.9)—— 那会被当普通文本或报错
MySQL 8.0 的 POINT 字段为什么 ST_Contains 总返回空
常见错误是字段类型用了 POINT 但没加空间索引，或者插入数据时没用 ST_GeomFromText 包装。MySQL 对空间函数非常严格：值必须是合法的 GEOMETRY 实例，且索引类型得是 SPATIAL，不是普通 INDEX。
实操建议：
- 建表时用
POINT NOT NULL，但必须配合SPATIAL KEY idx_loc (location) - 插入必须用
ST_GeomFromText('POINT(116.3 39.9)', 4326)，注意空格不是逗号，且 SRID 要和字段定义一致 - 查询前先确认
SELECT ST_IsValid(location) FROM table，很多失败是因为坐标反了（经/纬顺序错）、超出范围（纬度 >90）
PostGIS 中 CREATE INDEX 加 USING GIST 为什么报错 “type not supported”
这个错基本等于你在对非空间类型建 GIST 空间索引，比如字段是 TEXT 或 JSONB，或者类型是 GEOMETRY 但没装 PostGIS 扩展（CREATE EXTENSION postgis 漏了）。
实操建议：
- 先查类型：
\d+ your_table看字段是不是geometry或geography；再查扩展：SELECT * FROM pg_extension WHERE extname = 'postgis' - 建索引必须写全：
CREATE INDEX idx_geom ON places USING GIST (geom)，不能省略USING GIST—— 默认 B-tree 不支持空间操作符 - 如果字段是
GEOGRAPHY，索引仍用GIST，但内部优化不同；别试图用BRIN替代，它不支持空间谓词下推
GeoJSON 导入后空间查询慢，ST_DWithin 像没走索引
不是索引没建，而是查询里用了函数包裹字段，比如 ST_DWithin(ST_Transform(geom, 3857), ..., 1000) —— 这会让索引失效，因为数据库无法把索引键和运行时转换结果对齐。
实操建议：
- 索引字段和查询字段的 CRS 必须一致：如果索引建在
geom（4326），查询就用ST_DWithin(geom, ST_SetSRID(ST_MakePoint(x,y), 4326), 0.01)，距离单位是度（慎用），或统一转成GEOGRAPHY后用米 - 用
EXPLAIN确认是否走了Index Scan，而不是Seq Scan；如果看到Filter: st_dwithin(...)在外层，说明索引没生效 - 批量导入 GeoJSON 时，用
ST_GeomFromGeoJSON+ST_SetSRID一步到位，别先存 JSON 再运行时解析，那会彻底失去索引能力
空间索引不是建完就万事大吉，字段类型、SRID、函数写法、查询模式这四样只要有一样不匹配，就退化成全表扫描。最常被忽略的是：你以为在用 GEOGRAPHY，实际字段是 GEOMETRY，或者反过来。
