server anvender ikke Index

Hvordan ser din SQL-sætning ud?

denne køre under 1 sek
select sum(subtotal) FROM [AdventureWorks].[dbo].[test]with(Index=IX_test)  where fkeyid=8882

denne tager 1,20 min

select sum(subtotal) FROM [AdventureWorks].[dbo].[test]  where fkeyid=8882

er der statistikker på indexet? Hvis ikke vil serveren nok ikke engang prøve sig med det index.

Er du sikker på at du har lavet 2 index, og ikke 1 index med 2 kolonner? Hvis det er tilfældet, kan du ikke bruge indexet på søgefeltet, uden også at specificere autonum feltet.

Jeg har lavet to index og begge har kun et felt.

CREATE NONCLUSTERED INDEX [IX_test] ON [dbo].[test]
(
    [FKEYId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

ALTER TABLE [dbo].[test] ADD  CONSTRAINT [PK_test] PRIMARY KEY CLUSTERED
(
    [RowId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

--> teepee jeg er ikke sikker på jeg ved hvad du menere.

indsatte du rækker efter at du har oprettet indexet?
Sikkert nok, prøv at analysere tabellen

ja rækker er indsatte efter jeg har oprettet indexet..
Analyser tabellen?

Ved du ca. hvor mange rækker der matcher fkeyid'et 8882?

Da din sum-udregning beregner summen på en anden kolonne (subtotal), som ikke findes i dit index, så skal den for hver række i dit fkeyid-index lave et lookup i det clustered index, og det kan være derfor den vælger at lave et scan, hvis den vurderer at antal rækker med fkeyid 8882 er forholdsvist stort. Hvis du i stedet laver dit nonclustered index sådan her, så slipper du for lookup'et i dit clustered index, men det vil gøre index'et en smule større:

create nonclustered index IX_test on test (fkeyid) include (subtotal)

Dette virker dog vist kun på sql 2005 så vidt jeg husker.

koontz2 => statistikkerne er vigtige. Læs mere here om hvordan du opdaterer dem. Der kommer en lille reklame først, men der heldigvis et link til at skippe reklamen....
http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1278729,00.html#

Der er jo nok ikke noget i vejen med indekset: Det virker jo, når man tvinger optimizeren til at benytte det med et optimizer hint.

Et skud: Benytter optimizeren heller ikke indekset hvis du laver en subquery:

SELECT sum(subtotal)
FROM (
  SELECT subtotal
  FROM  [AdventureWorks].[dbo].[test]
  WHERE  fkeyid=8882)

På den anden side; hvis det virker, gør det så noget at du må give optimizeren et hint?

-->gnoname den anvender heller ikke indexet når jeg køre din query med subquery.
Nej du har ret det gør da ingen ting at hinte optimizeren men jeg var bare lidt rystet over at den ikke anvendte et
index der så tydelig  kunne optimere queryen. 

-->sjang du har sikkert ret i at det er fordi der er relativt mange rækker med 8882 ca 120000
At oprette et index med subtotal løser ikke mit problem da det kun var til min test, men det var jo ikke nemt at vide.

-->teepee Jeg har opdateret statistikkerne og udtrækket køre nu perfekt uden hint til indexet.




Tak for hjælpen til alle.

Jeg vil dele point mellem teepee og sjang hvis det er ok.
Begrundelsen er at sjang næsten helt sikkert har givet årsagen og teepee løsningen, håber det er ok.
smide i et svar ?

Velbekommen...

hmm troede man kunne dele points...sjang opretter en til dig