1

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

从几乎没有索引的查询到不到几秒的时间，几乎没有索引的查询有一个令人难以置信的性能提升，当缩放更近时它会变得更快，因此显示的对象更少。

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

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

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

谢谢你。

4

3 回答 3

0

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

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

于 2010-06-01T15:50:31.833 回答
0

是 SQL 还是 mapguide 守护进程的 CPU 利用率？

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

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

--

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

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

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

于 2009-11-30T03:22:57.617 回答
0

每当您遇到此类问题时，就该拿出 SQL Profiler 并查看正在执行的查询。然后通过查询计划器运行它们以查看瓶颈在哪里。

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

通常，您还可以优化针对服务器运行的查询，但是在 MapGuide 方面您有点缺乏选择；可能是 MapGuide 以 SQL Server 难以优化的方式提出问题。如果您发现是这种情况，请在 MapGuide Trac系统中输入一张票

于 2010-08-04T07:51:39.340 回答