13. november 2008 - 23:47Der er
8 kommentarer og 1 løsning
optimizeren scanner index i stedet for seek
Jeg har en tabel med +13 mill records hvor jeg har et clustered index på et datetime felt.. Når jeg køre en søgning f.eks ---------- SELECT [ProdOrderId] ,[WeightName] ,[WeightValue] ,[WeightTimeStamp]
FROM [tblWeightLog] WHERE WeightTimeStamp BETWEEN '2008-05-05' AND '2008-05-06' ------------- (retuner ca 90000 records på 1- 2 sek)
anvender optimizeren index scan i stedet for seek.
Jeg har opdaterede STATISTICS med 100 pct. Hvorfor scanner den og ville det være bedre med seek? Hvis ja hvordan tvinger jeg den så til seek.
janus_007, Det er muligt, men jeg har set lignende, hvor alene det at lave et covering index, tidoblede performance ;P Det er måske antallet af page accesses der gør det?
Laver den index scan på PK (som vel er ProdOrderID) eller på dit clustered index (som vel er WeightTimeStamp)?
Jeg står ved mit råd: Prøv at lave et covering index ;)
coderdk-> Ja til pages. Et bookmark lookup kan være tungt, også selvom optimizeren vælger index seek, specielt hvis data står hulter til bulter og der er aggregatfunktioner involveret. Til alt held er det løst bedre i SQL2005+, der findes nemlig en include: CREATE NONCLUSTERED INDEX IX_SalesOrderDetailCovering ON Sales.SalesOrderDetail (ProductID, SpecialOfferID) INCLUDE (SalesOrderID, SalesOrderDetailID, UnitPrice, OrderQty, UnitPriceDiscount);
Men ellers tak janus_007 :) Du kom med det rigtige svar, jeg synes du skal ha' det hele - Jeg kommer med glæde med gratis input/feedback - Jeg lærer også noget af og til :-D
Jeg kan godt mærke, at det er lang tid siden jeg har taget min MCP i SQL Server ;P
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Det er blevet kaldt ”det største it-nedbrud i historien” og omkostningerne kan nemt løbe op i syv milliarder kroner: Men hvem skal betale for Crowdstrikes fejl?
