我有一個包含數十萬個幾何類型地塊的SQL Server表。我已經爲它們製作了索引，嘗試每個單元格設置的密度和對象的不同組合。到目前爲止，我爲每個單元設置了LOW，LOW，MEDIUM，MEDIUM和16個對象，並且我創建了一個SP，根據表中實體的範圍設置邊界框。SQL Server 2008空間索引和CPU利用率與MapGuide開源2.1
無需索引就可以將幾乎幾分鐘的查詢時間縮短到幾秒鐘，而當縮放距離更近時，查詢會變得更快，從而減少顯示的對象。
即使查詢本身速度很快，查詢功能時CPU利用率也會達到100％。我擔心這不會在生產環境中飛行。
我正在爲此項目使用MapGuide Open Source 2.1，但我肯定CPU負載是由SQL Server引起的。
我不知道我的索引是否設置正確。我還沒有找到關於如何正確設置它們的明確文件。我讀過的每篇文章基本上都說「這取決於...」，但沒有具體。你有任何建議，包括書籍，文章嗎？
謝謝。
SQL或mapguide守護進程的CPU利用率是？
我們碰到的一個問題是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。 是的，我想我會關閉該級別的縮放數據，但它看起來很漂亮，實際上很有用。 – 2009-11-30 03:39:19
我們的數據跨越4個縣，在初始縮放時如此密集，實際上不可能顯示^^。不幸的是，我們使用Oracle，所以我不能評論SQL Server，除此之外，我對MG的架構知之甚少:( – Matt 2009-11-30 06:58:19
答案很簡單，概括你的數據，所以它的顯示優化
即創造出具有較少的細節一些附加表和緻密
你有這種問題的任何時間少，它的時間拔出SQL Profiler並查看正在執行的查詢。然後通過查詢計劃程序運行它們以查看瓶頸位置。
您也可以懶惰（像我一樣），只需使用Tuning Template記錄典型負載，然後通過數據庫引擎優化顧問運行它，查看它認爲您可以添加索引以提高性能的位置。
通常情況下，您還可以優化針對服務器運行的查詢，但在MapGuide方面您缺少選項; MapGuide可能會以難以對SQL Server進行優化的方式提出問題。如果您發現這種情況，請enter a ticket in the MapGuide Trac系統
謝謝大家。 實際的解決方案是**確保所有空間索引表都有一個主鍵定義**。 – 2011-05-06 05:53:54