即使在一個非常簡單的查詢中，我的SQL Server空間索引仍然需要大量的讀取。爲什麼？

我的trival查詢需要3秒才能返回，並需要根據SQL事件探查器進行大量的讀取操作。爲什麼？即使在一個非常簡單的查詢中，我的SQL Server空間索引仍然需要大量的讀取。爲什麼？

我有一張桌子，裏面裝滿了所有地理編碼點的5,000,000個帳戶。所有賬戶都聚集在一個城市20英里半徑範圍內。我的索引看起來像這樣。

CREATE SPATIAL INDEX [IX_CI_Geocode] ON [dbo].[CustomerInformation] 
(
    [Geocode] 
)USING GEOGRAPHY_GRID 
WITH (
GRIDS =(LEVEL_1 = HIGH,LEVEL_2 = HIGH,LEVEL_3 = HIGH,LEVEL_4 = LOW), 
CELLS_PER_OBJECT = 128, PAD_INDEX = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
GO

當我運行如下面所示，簡單的查詢：

DECLARE @g geography = geography::Point(41.848039, -87.96361, 4326); 
DECLARE @region geography = @g.STBuffer(5000); 

select count(0) from CustomerInformation ci WITH(INDEX(IX_CI_Geocode)) 
where ci.Geocode.STIntersects(@region) = 1

它需要3秒鐘返回，並根據SQL Server事件探查它要求的12203 CPU和1218873讀取。對於使用索引來說，這些似乎很大。

爲什麼這麼慢？爲什麼這需要從硬盤讀取這麼多？我能做些什麼來改善這方面的表現？

查看查詢計劃，下面屏幕截圖中的Filter運算符是查詢成本的34％。

enter image description here

的「聚集索引查找」操作符是查詢的63％。

enter image description here

來源

2011-08-04 Paul Mendoza

我對空間索引沒有任何經驗，但對我而言跳出來的是您估計的與實際的行數。通常這是過時統計的標誌。你有沒有嘗試更新表和索引的統計數據？ – JNK

好主意，但這並沒有最終幫助。我結束了使用另一種方法。 –

我的最終解決最終是使用濾鏡代替。它回饋了大量的誤報，但在性能方面速度提高了3倍。在得到結果集後，我應用距離函數來刪除那些我不關心的並且似乎很快的函數。

第一個選擇查詢在500萬個帳戶上需要1秒鐘。第二秒需要3秒。

DECLARE @g geography = geography::Point(41.848039, -87.96361, 4326); 
DECLARE @region geography = @g.STBuffer(5000); 

select count(0) from CustomerInformation ci WITH(INDEX(IX_CI_Geocode)) 
where ci.Geocode.Filter(@region) = 1 


select count(0) from CustomerInformation ci WITH(INDEX(IX_CI_Geocode)) 
where ci.Geocode.STIntersects(@region) = 1

來源

2011-08-04 20:14:14

根據我的數學技能，感覺就像額外的工作，如果你做STBuffer（）首先，如果你不是真的感興趣。

您能否爲我嘗試以下方法並報告結果？

DECLARE @g geography = geography::Point(41.848039, -87.96361, 4326); 

select count(0) from CustomerInformation ci WITH(INDEX(IX_CI_Geocode)) 
where ci.Geocode.STDistance(@g) <= 5000

另一方面，有沒有辦法可以提供數據庫，所以我可以自己測試它？

來源

2011-09-15 06:36:39 fabsenet

即使在一個非常簡單的查詢中，我的SQL Server空間索引仍然需要大量的讀取。爲什麼？

回答

相關問題