Avatar billede koontz2 Nybegynder
13. november 2008 - 23:47 Der 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.


På forhånd tak
Avatar billede coderdk Praktikant
14. november 2008 - 00:18 #1
Har du overvejet at lave et covering index? Altså et index hvor ProdOrderId, WeightName, WeightValue er indekseret sammen med WeightTimeStamp?
Avatar billede janus_007 Nybegynder
14. november 2008 - 00:56 #2
Hej koontz2

Prøv lige at fyre flg. af: sp_helpindex tblWeightLog og post det her!

Hvilken datatype er WeightTimeStamp?

coderdk-> hvis kolonnenavnene ikke er dækket af indexet vil det blot resultere i et bookmark lookup :)
Avatar billede coderdk Praktikant
14. november 2008 - 01:50 #3
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 ;)
Avatar billede koontz2 Nybegynder
14. november 2008 - 08:46 #4
ja det ser ud til at jeg har kvajet mig
sp_helpindex tblWeightLog viste fejlen 
forkert kolonne navn
skulle nok være stoppet lidt før igår..

janus_007 smid et svar
Avatar billede janus_007 Nybegynder
14. november 2008 - 14:41 #5
Lad os dele det, coderdk :)

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);

Magic *S*
Avatar billede coderdk Praktikant
14. november 2008 - 14:47 #6
Ja, det er sgu smart :)

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
Avatar billede janus_007 Nybegynder
14. november 2008 - 15:33 #7
Jamen tak så. Jeg er nu også glad for bare at kunne hjælpe.
Avatar billede koontz2 Nybegynder
17. november 2008 - 08:06 #8
I for begge tak for hjælpen..

MVH Poul
Avatar billede koontz2 Nybegynder
19. november 2008 - 20:57 #9
prøver og give points igen
Avatar billede Ny bruger Nybegynder

Din løsning...

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.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester



Seneste spørgsmål Seneste aktivitet
I dag 06:10 Excel åbner fil i kæmpe format Af Aske i Excel
I går 22:00 Datafordeler Af Lsk i PHP
I går 12:37 Summere beløb pr. dato Af TTA i Excel
31/1022:44 Tilslutte chassic fans Af viking69 i PC
31/1020:28 LED lysstofrør Af ErikHg i Fri debat