视图封装空间函数和join可降低gis查询门槛，但需确保srid统一、显式创建gist索引、避免嵌套视图与高开销函数，否则引发性能退化或执行计划失效。
直接结论：用视图封装空间函数调用和JOIN逻辑，能显著降低GIS查询的使用门槛，但必须注意SRID一致性、索引缺失和嵌套视图带来的执行计划退化。
为什么不能直接在应用层拼SQL做ST_Intersects？
每次写 SELECT * FROM buildings b, zones z WHERE ST_Intersects(b.geom, z.geom)，都要手动确认两点：一是两个 geom 字段是否同为 GEOMETRY(Polygon,4326) 类型，二是是否已对 b.geom 和 z.geom 分别建了 GIST 索引。漏掉任一环节，查询可能从毫秒级变成分钟级。视图把这类校验和约定固化下来，避免重复出错。
- 常见错误现象：
ERROR: Operation on two GEOMETRIES with different SRIDs—— 视图创建时若没显式用ST_Transform统一坐标系，运行时才报错 - 使用场景：多个业务模块都要查“某点500米内的POI”，但各自写一遍
ST_DWithin(ST_SetSRID(ST_MakePoint(lon, lat), 4326), geom, 0.005)容易参数不一致（比如有人用0.004、有人忘了ST_SetSRID） - 性能影响：未加索引的
geom字段在视图里参与ST_Contains，会导致全表扫描，而视图本身不强制建索引
CREATE VIEW时必须显式处理SRID和索引
PostgreSQL 视图不存储数据，也不自动继承基础表的索引或约束。你得自己确保底层空间字段已启用 GIST 索引，并在视图定义中显式转换坐标系。
- 正确做法：先在基础表上执行
CREATE INDEX ON buildings USING GIST (geom)，再创建视图 - 必须写
ST_Transform(geom, 32650)或ST_SetSRID(geom, 4326)，不能依赖隐式转换 - 避免在视图里用
ST_Buffer(geom, 100)这类高开销函数——它会在每次查询时重算，应提前物化或用函数索引替代 - 示例：
CREATE VIEW nearby_pois AS SELECT p.id, p.name, ST_Distance(p.geom, ST_SetSRID(ST_MakePoint(116.4, 39.9), 4326)) AS dist_m FROM pois p WHERE ST_DWithin(p.geom, ST_SetSRID(ST_MakePoint(116.4, 39.9), 4326), 0.005);
嵌套视图会让EXPLAIN输出难以解读
当你有 view_a → view_b → view_c 的链式依赖，EXPLAIN ANALYZE 显示的执行计划里，Seq Scan on view_c 实际可能是扫描三张物理表+两次空间函数计算。PostgreSQL 不会展开视图定义来优化，它只按“视图是黑盒”处理。
- 容易踩的坑：以为给
view_c加了索引就能加速SELECT * FROM view_a，其实无效 - 调试建议：用
\d+ view_name查看视图定义，复制SQL到EXPLAIN中手动展开测试 - 参数差异：视图无法接收运行时参数（如动态坐标），要用
sql_mode=postgres风格的函数包装，例如CREATE FUNCTION nearby_pois(lat double precision, lon double precision) RETURNS TABLE(...) - 兼容性影响：含
ST_Centroid或ST_Simplify的视图，在低版本PostGIS中可能因函数签名变化而失效
最常被忽略的是：视图里用 ST_AsText(geom) 或 ST_Transform 会阻止GIST索引下推，哪怕底层字段本身有索引。真要简化查询，优先考虑物化视图（CREATE MATERIALIZED VIEW）或函数封装，而不是无脑套一层VIEW。
