关于SQL Server性能的ArcGIS 10.2查询层

我在ArcMap中的SQL Server上使用查询层。查询层可在SQL Server中立即执行，但在ArcMap中绘制需要花费很长时间，以至于系统在大约10分钟或更长时间内无响应。在ArcMap绘制期间，SQL Server进程中的CPU之一已用尽。

我的查询是线要素（Shannon）上与多边形要素类（Townlands）相对的缓冲区的STIntersects；如下所示；

SELECT TOWNLANDS.TL_ID,TOWNLANDS.Shape FROM dbo.TOWNLANDS as townlands
with(index(FDO_Shape)) 
JOIN dbo.Shannon on townlands.Shape.STIntersects 
(Shannon.Shape.STBuffer(2.0))=1

查询立即返回186行。可以在“ SQL Server Management Studio空间”窗格中绘制它们，而不会出现问题

当我使用完全相同的语法在ArcMap中构建查询图层时，系统变得无响应，但最终会绘制。似乎ArcMap似乎未使用空间索引，或者这样做与SQL Server有所不同，这导致SQL Server上的查询效率低下，并且需要一定的时间才能返回。

谁能建议补救措施？

谢谢

ArcGIS Desktop: 10.2
ArcSDE: 10.2
RDBMS: Database and version: SQL Server 2008
OS: Windows Server 

如您所述，查询似乎在数据库级别迅速执行。即使能够提高SQL的效率，真正的性能还是在空间级别上。

像您正在使用的那样，空间SQL语句仅在引入几何类型后才被允许。用于ArcSDE的SQL Server 2008支持三种几何数据类型：SDEBINARY，GEOMETRY和GEOGRAPHY。区别在这里列出

为了获得最佳性能，请确保根据数据的性质使用几何或地理（尽管已过时并且不建议使用SDEBINARY，但不要使用SDEBINARY），无论是否使用地球空间参考。另外，还要确保在TOWNLANDS要素类上重建空间索引。您可以通过在ArcCatalog中右键单击要素类，属性并选择“索引”选项卡来执行此操作。

希望能有所帮助。

我没有在您的查询中看到需要进行联接。改用WHERE。

SELECT TOWNLANDS.TL_ID,TOWNLANDS.Shape 
FROM dbo.TOWNLANDS as townlands
with(index(FDO_Shape)) 
WHERE townlands.Shape.STIntersects 
(Shannon.Shape.STBuffer(2.0))=1

在原始查询中，联接似乎对结果没有好处；我在选择行中没有看到Shannon表中的任何列。因此，这似乎是多余的工作。

据我所知，这是将ArcGIS与SQL Server一起使用的已知限制，但没有一个简单的修复程序。

如果SQL Server查询计划程序决定它需要多个CPU来执行查询，则所使用的空间索引的几率很低。

Microsoft已经意识到了这个问题，但并不急于改进查询计划程序，因为它将影响所有查询，而不仅仅是空间查询。

唯一可靠的解决方案是将数据库上的最大并行度（MAXDOP）设置为1，但这意味着该数据库上的所有查询每个查询将仅使用1个CPU，从而降低了一切速度。

创建表示表的视图并强制使用空间索引提示的视图无法正常工作，因为ArcGIS需要查询表的元数据和统计信息，而这种视图会终止这些查询。

我有一个类似的问题。我有一个要素类，以Geometry类型存储在SQL Server中。它有30m条记录，并且绘制良好，但是如果您创建链接到第二张表的VIEW，则该VIEW会挂起并且不会显示。

该表具有附加的关系类负载。这些会影响查询/绘图性能吗？

您也可以指出我对微软对这个问题的认可的方向。我可以强制查询计划器使用空间索引吗？

法案