视图查询索引“失效”本质是查询逻辑无法穿透到基表索引列，因视图定义（如STTransform）或调用方式破坏了索引下推条件；空间索引仅绑定原生geometry/geography列，函数输出值导致全表扫描。
视图查询时索引“失效”，不是视图本身屏蔽了索引，而是查询逻辑无法穿透到基表 spatial 或普通索引列上——根本问题出在视图定义或调用方式破坏了索引下推条件。
为什么视图里加个 STTransform 就不走空间索引
SQL Server 和 PostgreSQL 的空间索引只绑定在基表的原生 geometry 或 geography 列上，任何函数输出的新 spatial 值（如 STTransform()、STBuffer()、STAsText()）都会让优化器放弃索引下推。执行计划中 type 会显示 Table Scan，key 为 NULL。
- 视图定义含计算列：比如
SELECT id, loc.STTransform(4326) AS wgs84_loc FROM places，哪怕你在外部写WHERE wgs84_loc.STIntersects(@poly) = 1，也必然全表扫描 - 简单投影视图才可能下推：仅
SELECT id, name, location FROM places这类无变换、无聚合、无 JOIN 的定义，且外部WHERE直接引用location列时，空间索引才可能生效 - SQL Server 不允许在视图上建空间索引：
CREATE SPATIAL INDEX语句不接受视图名，报错Incorrect syntax near 'VIEW'
EXPLAIN 看不到 key？先确认是不是真在查视图
很多人误以为自己在查视图，实际执行的是展开后的基表语句，但没意识到视图定义已让谓词无法下推。排查必须分两步走：
- 第一步：对视图本身运行
EXPLAIN SELECT * FROM my_spatial_view WHERE ...，看key是否为NULL，Extra是否含Using where; Using index - 第二步：手动提取视图定义中的
SELECT语句，去掉视图壳，直接在基表上跑相同WHERE条件，对比执行计划是否一致 - 如果基表能走索引、视图不能 → 问题在视图结构；如果基表也不走 → 问题在查询写法或索引缺失
联合索引 + 视图 = 最左前缀大概率被截断
视图若含 GROUP BY、DISTINCT、窗口函数或非确定性 ORDER BY，优化器基本放弃谓词下推，联合索引的最左前缀原则就形同虚设。
- 例如基表有复合索引
(user_id, status, created_at)，视图定义为CREATE VIEW v_orders AS SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id，此时外部加WHERE status = 'paid'完全无效——status列根本不在视图结果集中 - 即使视图保留所有列，只要用了
TOP、OFFSET-FETCH或UNION ALL（无ORDER BY），SQL Server 2019+ 也极少下推 spatial 或普通索引谓词 - MySQL 8.0 对视图支持更弱：带
JOIN的视图默认禁用索引下推，除非显式启用merge algorithm，但 spatial 函数仍不可穿透
别用视图封装 spatial 过滤，改用内联表值函数（ITVF）
比修视图更可靠的做法，是把 spatial 谓词逻辑前移到可参数化的 ITVF 中，强制让调用方把几何参数传进来，避免在视图层做任何转换。
- 错误示范（视图）：
CREATE VIEW v_near_parks AS SELECT *, location.STDistance(@point) dist FROM parks→dist列无法触发空间索引 - 正确替代（ITVF）：
CREATE FUNCTION fn_parks_near(@point geography) RETURNS TABLE AS RETURN (SELECT id, name, location FROM parks WHERE location.STIntersects(@point.STBuffer(500)) = 1) - 调用时：
SELECT * FROM fn_parks_near(@my_point)→ 执行计划明确显示key = <spatial_index_name></spatial_index_name> - 优势：ITVF 是单语句、无状态、可内联展开的，优化器能完整看到基表 + 谓词，索引下推成功率远高于视图
真正卡住人的点，往往不是“有没有索引”，而是“有没有让数据库在执行计划生成阶段，就把 WHERE 条件和索引列关联起来”。视图的抽象层容易掩盖这一层依赖，排查时务必撕开视图外壳，直击基表语句与执行计划的对应关系。
