MSSQL空间索引在多谓词查询场景下未被使用的问题

这个问题我之前也碰到过，SQL Server的空间索引对OR连接的多空间谓词支持确实不太友好，原因和优化器的决策逻辑以及空间索引的底层设计有关：

核心原因 #

SQL Server的空间索引是基于网格划分实现的，每个地理对象会被映射到对应的网格单元格中。当你用OR连接两个STDistance条件时，优化器很难找到一个高效的方式来同时利用索引覆盖两个不同的空间范围——两个点的周边区域对应的网格可能完全不重叠，优化器会认为两次索引查找再合并结果的成本，反而不如直接全表扫描来得低，因此会放弃使用空间索引。

可行的解决方案 #

1. 用UNION ALL拆分查询（最可靠的方法）

把OR条件拆分成两个独立的查询，每个查询单独使用空间索引，最后用UNION ALL合并结果。这样每个子查询都能正常触发空间索引：

-- 第一个空间范围查询
SELECT * 
FROM Location WITH (INDEX (SpatialIndex_GeoLocation)) 
WHERE GeoLocation.STDistance(GEOGRAPHY::STGeomFromText('POINT(4.271942 52.085289)', 4326)) < 50

UNION ALL

-- 第二个空间范围查询
SELECT * 
FROM Location WITH (INDEX (SpatialIndex_GeoLocation)) 
WHERE GeoLocation.STDistance(GEOGRAPHY::STGeomFromText('POINT(替换成你的第二个坐标)', 4326)) < 50

注意：如果你的数据可能存在重复（同一行满足两个条件），可以用UNION代替UNION ALL来去重，但UNION会额外增加排序去重的成本，优先选择UNION ALL。

2. 更新统计信息

如果你的表数据有过大量变更，过时的统计信息可能会误导优化器的决策。可以执行以下语句更新统计信息，让优化器重新评估索引使用的成本：

UPDATE STATISTICS Location;

3. 尝试强制重新编译执行计划

在查询末尾加上OPTION(RECOMPILE)，强制优化器重新生成执行计划，有时候能让它选择使用空间索引，但这个方法的稳定性不如拆分查询：

SELECT * 
FROM Location WITH (INDEX (SpatialIndex_GeoLocation)) 
WHERE GeoLocation.STDistance(GEOGRAPHY::STGeomFromText('POINT(4.271942 52.085289)', 4326)) < 50
   OR GeoLocation.STDistance(GEOGRAPHY::STGeomFromText('POINT(替换成你的第二个坐标)', 4326)) < 50
OPTION(RECOMPILE);

内容的提问来源于stack exchange，提问作者David