2014-05-14 57 views
2

我有一個非常高效的SQL查詢,但我有一種感覺可以改進。優化一個已經在做索引查詢的SQL查詢

這是索引尋找後使用IX_thing_time_location之後的排序的48%,我希望可以改進。我不想認爲這是用這個查詢可以做的最好的。除了更新查詢,更改索引,分區(我知道這些並不總是意味着性能提升),我還可以做其他什麼來提高性能?

下面是執行計劃:http://pastebin.com/G4Zi2tnw

我試圖將其粘貼在這裏,但它太大。

指數的定義:

CREATE NONCLUSTERED INDEX [IX_thing_time_location] ON [dbo].[tippy] 
(
    [time_start] ASC, 
    [location] ASC 
) 
INCLUDE ( [id], 
    [name], 
    [time_end], 
    [is_meetup], 
    [utc_offset], 
    [type], 
    [all_day]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
GO 

存儲過程:

ALTER PROCEDURE [dbo].[GetthingsByLatLong] 
@minLat FLOAT, 
@maxLat FLOAT, 
@minLong FLOAT, 
@maxLong FLOAT, 
@startTime BIGINT, 
@endTime BIGINT 
AS 

SELECT id, name, latitude, longitude 
INTO #templocations 
FROM locations 
WHERE latitude BETWEEN @minLat AND @maxLat 
AND longitude BETWEEN @minLong AND @maxLong 
ORDER BY id; 

-- This is a container 
-- Get all "routes" (containers) within a given lat/long combo 
SELECT thing_routes.* 
INTO #tempRoutes 
FROM thing_routes 
WHERE latitude BETWEEN @minLat AND @maxLat 
AND longitude BETWEEN @minLong AND @maxLong; 


-- Get all things which are in the above containers 
SELECT tip.id, tip.name, tip.location, tip.time_start, tip.time_end, tip.is_meetup, 
tip.utc_offset, tip.[type], tip.all_day, 
#tempRoutes.id AS route_id, locations.name AS location_name, 
locations.latitude AS latitude, locations.longitude AS longitude 
INTO #tempRoute_things 
FROM #tempRoutes 
INNER JOIN link_thing_routes 
ON link_thing_routes.route_id = #tempRoutes.id 
INNER JOIN locations 
ON locations.id = #tempRoutes.location 
INNER JOIN thing AS tip 
ON link_thing_routes.thing_id = tip.id; 


-- Return the data 
SELECT * FROM #tempRoutes 


-- Return the data - Add in the things from external_thing_routes 
-- Join the two tables from earlier, filtering on time 
SELECT tip.id, tip.name, tip.location, tip.time_start, tip.time_end, tip.is_meetup, 
tip.utc_offset, tip.[type], tip.all_day, NULL as route_id, #templocations.name AS location_name, 
#templocations.latitude AS latitude, #templocations.longitude AS longitude 
FROM #templocations 
INNER MERGE JOIN thing AS tip 
ON #templocations.id = tip.location 
WHERE time_start BETWEEN @startTime AND @endTime 



SELECT external_thing_routes.thing_id, external_thing_routes.route_id 
FROM external_thing_routes 
+0

包含在[IX_thing_time_location]索引哪些列。 –

+0

@AnthonyHorne - 我將它添加到問題中。 – Faraday

+1

也許看看有多少I/O發生和篩選索引。 –

回答

0

我沒有看劇本解釋,但我已經碰到了類似的問題。

是否在與選擇相同的索引中排序的列?如果你有這樣的查詢:

select * 
from exampletable 
where foreignkey = somevalue 
order by column1, column2 

一個指標應該是

foreignkey, column1, column2 
+0

概念這背後其實是正確的 –