SQL Server Spatial中STIntersects疑似存在Bug

我仔细梳理了你提到的问题——在SQL Server 2012和2017版本中，STIntersects函数出现了不符合预期的行为，结合你提供的测试脚本片段，确实有可能是空间函数的Bug，不过我们可以先通过几个步骤进一步验证：

首先补全并验证测试脚本 #

你提供的多边形WKT被截断了，地理类型的多边形必须是闭合的（首尾坐标完全一致），否则函数可能出现异常行为。建议先补全完整的WKT，再搭配一个明确的测试对象（比如点或另一个多边形）执行完整的相交判断，示例脚本如下：

DECLARE @g geography;
DECLARE @h geography;
-- 补全闭合的多边形WKT（示例中补充了收尾点和缺失的顶点）
SET @g = geography::STPolyFromText('POLYGON ((-2.2141931466053393 36.848142880725426, -2.1632066297350296 36.864255247830073, 3.0526676842932088 39.266689645726004, 3.168352172454167 39.329935703712941, 3.2286305251469463 39.370418565526464, 3.2322979289615716 39.374091534163213, 3.237288279596389 39.380123456789, -2.2141931466053393 36.848142880725426))', 4326);
-- 测试用的点（位于多边形大致范围内）
SET @h = geography::STPointFromText('POINT (0 38)', 4326);
-- 执行相交判断
SELECT @g.STIntersects(@h) AS IsIntersecting;

关键排查点 #

在确认Bug之前，先排除几个常见的人为因素：

• SRID一致性：确保@g和@h使用相同的空间参考标识符（默认是4326），不同SRID会导致函数返回不可靠结果
• 多边形有效性：执行SELECT @g.STIsValid()检查多边形是否有效，无效的几何对象会导致空间函数行为异常
• 精度问题：如果多边形顶点包含极高精度的坐标，尝试截断到6-8位小数后再测试，某些情况下精度溢出会干扰函数计算

若确认是Bug的处理方式 #

如果经过上述验证后，STIntersects的返回结果仍然明显不符合预期（比如视觉上相交的对象返回0，或不相交的返回1），这大概率是SQL Server空间引擎的Bug：

1. 可以查看微软官方的SQL Server知识库，确认是否有已记录的类似Bug（比如针对复杂多边形相交判断的修复补丁）
2. 如果是未记录的Bug，建议通过SQL Server反馈中心提交完整的可复现脚本、预期结果和实际结果，微软的工程师会进行排查和修复

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