我有一个包含数十万个几何类型parcel的SQL Server表。我已经为它们制作了索引，尝试不同的密度和每个单元格对象设置的组合。到目前为止，我正在为每个单元格设置LOW，LOW，MEDIUM，MEDIUM和16个对象，我制作了一个SP，根据表格中实体的范围设置边界框。
从几十分钟没有索引的查询到小于几秒的时间内，性能得到了令人难以置信的提升，当缩放距离越近时，它就越快，因此显示的对象越少。
然而，查询功能时CPU利用率达到100％，即使查询本身很快。我担心这不会在生产环境中飞行。
我正在为这个项目使用MapGuide Open Source 2.1，但我很肯定CPU负载是由SQL Server引起的。
我想知道我的索引是否设置正确。我没有找到关于如何正确设置它们的任何明确文档。我读过的每篇文章都基本上都说“这取决于......”但没有具体说明。你有什么建议给我，包括书籍，文章吗？
谢谢。
答案 0 :(得分：0)
是SQL还是mapguide守护程序的CPU利用率？
我们遇到的一个问题是，mapguide对于编写查询并不聪明。如果您处于最大缩放状态并显示图例的一小部分（例如仅表示该缩放级别的传输），它将查询视图区域内的每个对象，而不应用任何其他过滤器。然后它循环遍历数千条记录并应用主题（使用单独的过滤器）。
你可以尝试做的是为不同的缩放级别编写图层，并使用查询过滤器来限制从SQL返回的数据量（这可能是占用了大量的CPU时间）。与20秒相比，这减少了我们的传输和配电线路上的初始加载时间（唯一有意义的显示在该级别上），时间缩短到几毫秒。
-
我所说的是确保您只是请求图层所需的数据。假设您显示ID 1,2,3和4。
假设你有0级的显示1和2 - >无穷。虽然3和4只在20,000英尺处踢。默认情况下，mapguide基本上会使用视口的边界框执行select *。然后它将遍历应用主题的所有数据。
所以说30,000英尺它将查询所有数据，但仍然需要遍历它。
答案 1 :(得分：0)
简单的答案是概括您的数据，因此它针对显示进行了优化
即创建一些细节较少且密度较小的附加表
答案 2 :(得分：0)
任何时候遇到这种问题，都需要抽出SQL事件探查器并查看正在执行的查询。然后通过查询计划程序运行它们以查看瓶颈所在。
您也可能是懒惰的（像我一样），只使用调优模板记录典型负载，然后通过数据库引擎优化顾问运行它，看看它认为您可以添加索引以提高性能。
通常情况下，您也可以优化针对服务器运行的查询，但是当涉及MapGuide时，您的选项有点缺乏;可能是MapGuide以一种SQL Server难以优化的方式提问。如果您发现这种情况，请enter a ticket in the MapGuide Trac system