使用 MapGuide Open Source 2.1 的 SQL Server 2008 空间索引和 CPU 利用率答案

【问题标题】：SQL Server 2008 spatial index and CPU utilization with MapGuide Open Source 2.1使用 MapGuide Open Source 2.1 的 SQL Server 2008 空间索引和 CPU 利用率
【发布时间】：2009-11-30 02:59:37
【问题描述】：

我有一个包含数十万几何类型宗地的 SQL Server 表。我已经对它们进行了索引，尝试在每个单元格设置中尝试不同的密度和对象组合。到目前为止，我正在为每个单元格设置 LOW、LOW、MEDIUM、MEDIUM 和 16 个对象，并且我制作了一个 SP，它根据表中实体的范围设置边界框。

在没有索引的情况下几乎需要几分钟的查询时间到不到几秒的查询，性能得到了惊人的提升，当缩放更近时它变得更快，因此显示的对象更少。

然而，在查询特征时 CPU 利用率达到 100%，即使查询本身速度很快。我担心这不会在生产环境中运行。

我在这个项目中使用 MapGuide Open Source 2.1，但我确信 CPU 负载是由 SQL Server 引起的。

我想知道我的索引是否设置正确。我还没有找到任何关于如何正确设置它们的明确文档。我读过的每篇文章基本上都说“这取决于......”但没有具体说明。你有什么推荐给我的吗，包括书籍、文章？

谢谢。

【问题讨论】：

谢谢大家。实际的解决方案是确保所有空间索引表都定义了主键。

标签： sql-server performance gis geospatial mapguide

【解决方案1】：

CPU 利用率是在 SQL 上还是在 mapguide 守护程序上？

我们遇到的一个问题是 mapguide 在编写查询方面并不那么聪明。如果您以最大缩放并显示图例的一小部分（例如仅在该缩放级别传输），它将查询视图区域内的每个对象，而无需应用任何其他过滤器。然后它会遍历数千条记录并应用主题（使用单独的过滤器）。

您可以尝试为不同的缩放级别编写图层，并使用查询过滤器来限制从 SQL 返回的数据量（这可能是占用大量 CPU 时间的原因）。与 20 多秒相比，这将我们的输配电线路的初始加载时间（在该级别显示的唯一有意义的东西）减少到几毫秒。

我所说的是确保您只请求图层所需的数据。假设您显示 ID 1、2、3 和 4。

假设您在 0 -> 无穷大的范围内显示 1 和 2。而 3 和 4 只在 20,000 英尺处开始。默认情况下，mapguide 基本上会使用视口的边界框进行选择 *。然后它将遍历所有应用主题的数据。

所以在 30,000 英尺处，它将查询所有数据，但仍需要循环遍历它。

【讨论】：

我很确定它是 SQL Server。 Mapguide 确实启动了，但它只是在 SQL Server 完成后的一瞬间，并且不会超过 50% 的 CPU。是的，我想我会关闭该级别缩放的数据，但它看起来确实很漂亮，实际上很有用。
我们的数据跨越 4 个县，在初始缩放时非常密集，几乎无法显示 ^^。不幸的是，我们使用 Oracle，所以我无法评论 SQL Server，除了我对 MG 架构的了解:(

【解决方案2】：

简单的答案是概括您的数据，因此针对显示进行了优化

即创建一些细节较少且密度较小的附加表

【讨论】：

【解决方案3】：

任何时候你有这样的问题，是时候拿出 SQL Profiler 看看正在执行什么查询。然后通过查询计划器运行它们以查看瓶颈在哪里。

您也可能很懒惰（像我一样），只使用优化模板记录典型负载，然后通过数据库引擎优化顾问运行它，看看它认为您可以在哪里添加索引以提高性能。

通常，您还可以优化针对服务器运行的查询，但是在 MapGuide 方面您有点缺乏选择；可能是 MapGuide 以 SQL Server 难以优化的方式提出问题。如果您发现是这种情况，请enter a ticket in the MapGuide Tracsystem

【讨论】：