视图无法优化空间查询性能，真正起效的是底层表的spatial索引及正确使用st_within、mbrcontains等可下推谓词；应避免在视图中嵌入st_distance_sphere等计算，而应在查询中结合空间索引预过滤。
MySQL 中的视图本身无法直接“优化”空间查询性能——它只是封装了 SQL，执行时仍会原样展开。真正起作用的是底层表的空间索引（SPATIAL 索引）和空间函数的写法是否可被优化器识别并利用。
为什么视图里用 ST_Distance_Sphere 会变慢
常见错误是把计算逻辑全塞进视图定义，例如：
CREATE VIEW nearby_stores AS SELECT id, name, ST_Distance_Sphere(location, POINT(-73.9857, 40.7484)) AS distance FROM stores;
这会导致每次查 nearby_stores 都强制对全表每行调用 ST_Distance_Sphere，无法走索引，等价于全表扫描 + 计算。
- MySQL 8.0+ 的
ST_Distance_Sphere是标量函数，不参与空间索引过滤 - 视图不会提前物化或缓存距离值，也不会自动加
WHERE条件 - 如果上层查询再加
WHERE distance ，优化器仍无法下推过滤，只能先算完再筛
必须在视图外显式使用 ST_Within 或 MBRContains 过滤
空间索引（SPATIAL）只对特定谓词生效：ST_Within、ST_Contains、ST_Intersects、MBRContains 等。这些能触发索引快速定位候选行。
正确做法是：视图只做轻量封装，把空间过滤逻辑留给调用方
CREATE VIEW stores_geo AS SELECT id, name, address, location FROM stores;
然后在实际查询中主动用空间索引：
SELECT id, name,
ST_Distance_Sphere(location, POINT(-73.9857, 40.7484)) AS distance
FROM stores_geo
WHERE ST_Within(location, ST_Buffer(POINT(-73.9857, 40.7484), 5000));
-
ST_Buffer(..., 5000)生成一个近似圆形范围（单位：米），ST_Within可走SPATIAL索引 - 即使
ST_Buffer不够精确，它也大幅缩小候选集，后续ST_Distance_Sphere只需计算少量行 - 务必确认
stores.location字段已建SPATIAL索引：ALTER TABLE stores ADD SPATIAL INDEX idx_location (location);
ST_Distance_Sphere 在 WHERE 中无法走索引，但可配合 ORDER BY ... LIMIT 用
如果你要找“最近的 10 家店”，不要写 WHERE ST_Distance_Sphere(...) ，而应依赖排序 + 截断 + 索引预过滤：
SELECT id, name,
ST_Distance_Sphere(location, POINT(-73.9857, 40.7484)) AS distance
FROM stores_geo
WHERE MBRContains(
ST_MakeEnvelope(
ST_X(POINT(-73.9857, 40.7484)) - 0.05,
ST_Y(POINT(-73.9857, 40.7484)) - 0.05,
ST_X(POINT(-73.9857, 40.7484)) + 0.05,
ST_Y(POINT(-73.9857, 40.7484)) + 0.05,
4326
),
location
)
ORDER BY distance
LIMIT 10;
-
MBRContains+ST_MakeEnvelope利用最小边界矩形（MBR），100% 走SPATIAL索引 - 经纬度 ±0.05° 约等于 ±5.5km，足够作为粗筛范围
-
ORDER BY distance LIMIT 10会让 MySQL 先取满足 MBR 的行，再逐个算距离并堆排序，比全表算快得多
别在视图里用 ST_AsText、ST_X 等函数暴露坐标字段
有人为方便前端使用，在视图里直接拆出 lng 和 lat：
CREATE VIEW stores_flat AS SELECT id, name, ST_X(location) AS lng, ST_Y(location) AS lat FROM stores;
这看似方便，但代价严重：
- 每次查询都强制执行函数提取，无法走
SPATIAL索引 - 丢失原始
POINT类型语义，后续无法再用任何空间函数高效过滤 - 若业务真需要经纬度字段，应在表里冗余存储
lng/lat并单独建普通 B-tree 索引，而不是靠函数实时转换
空间查询性能瓶颈几乎总在 I/O 和计算密度，而不是视图语法本身；关键在于让每一层（建表、索引、视图、查询）各司其职——视图只负责字段投影与权限隔离，空间过滤和距离计算必须由调用方显式、有策略地组织。
