postgresql+postgis是唯一可行方案，mysql和sql server空间能力弱；视图需用st_makepoint+st_setsrid构造几何，字段顺序为经度、纬度，text类型须转double precision，索引须建在基表而非视图，st_dwithin单位默认为坐标系单位（如4326下为度），推荐转geography类型以米为单位。
PostgreSQL + PostGIS 是唯一实际可行的方案，MySQL 和 SQL Server 的空间视图能力太弱，别硬上。
PostGIS 中用 ST_MakePoint 构建点几何并创建视图
视图本身不存数据，所以必须在 SELECT 里实时构造几何对象。常见错误是直接写 POINT(x y) 字符串——PostgreSQL 不认这个语法，会报错 column "point" does not exist。
正确做法是用 ST_MakePoint 配合 ST_SetSRID 显式指定坐标系（比如 WGS84 对应 SRID 4326）：
CREATE VIEW user_locations AS
SELECT id, name,
ST_SetSRID(ST_MakePoint(longitude, latitude), 4326) AS geom
FROM users;
- 必须用
ST_SetSRID，否则geom是“unknown”类型，后续ST_DWithin等函数会报错 - 字段顺序是
longitude, latitude（经度在前），反了会导致位置偏移几千公里 - 如果原始表里
longitude/latitude是TEXT类型，得先用::double precision强转，否则ST_MakePoint拒绝执行
视图中加空间索引？不行，但可以建在基表上
PostgreSQL 不允许对视图建 GIST 索引，试图运行 CREATE INDEX ON user_locations USING GIST (geom) 会提示 cannot create index on view。
真正起效的方式是：确保基表（如 users）上已有空间列，并在该列建索引：
ALTER TABLE users ADD COLUMN geom geometry(POINT, 4326); UPDATE users SET geom = ST_SetSRID(ST_MakePoint(longitude, latitude), 4326); CREATE INDEX idx_users_geom ON users USING GIST (geom);
- 视图查询时，只要
WHERE条件里用了空间函数（如ST_Contains），且底层基表有对应 GIST 索引，查询计划就会走索引 - 别在视图里再套一层
ST_Transform投影转换——这会让索引失效，除非你同时在基表上存了投影后的几何列
用 ST_DWithin 做距离过滤时单位容易搞错
PostGIS 默认单位是「坐标系单位」，WGS84（SRID 4326）下是「度」，不是米。直接写 ST_DWithin(geom, ST_MakePoint(...), 1000) 意思是“1000 度”，相当于绕地球好几圈。
两种安全写法：
- 用
geography类型（推荐）：ST_DWithin(geom::geography, ST_MakePoint(lng, lat)::geography, 1000)——单位就是米 - 用
ST_Transform转到投影坐标系（如 Web Mercator SRID 3857）：ST_DWithin(ST_Transform(geom, 3857), ST_Transform(ST_MakePoint(...), 3857), 1000)，单位也是米 - 千万别混用：比如
geom是 4326，却用ST_DWithin(geom, ..., 1000)还以为是 1000 米
最常被忽略的是：视图定义里不能包含未声明的函数依赖（比如自定义的 ST_SafeMakePoint），一旦函数被删或改名，视图查询直接报错 function does not exist，而且错误位置很难定位。
