Er der nogen der har nogle forslag til hvordan man kunne performance-optimere disse SQL sætninger i stored procedures, så de ikke sluger så meget cpu når der er rush på? Vil helst gerne af med de 2 interne select-sætninger hvis det kan lade sig gøre... eller i det mindste kunne genbruge dem på en eller anden måde, da de er tæt på at være ens.
Den første:
SELECT @iNumChallWon=count(ChallengeID) FROM Challenges WHERE ID2Accept = 1 AND EndDate < getdate() AND (ID1 = @CarId AND ID1Votes > ID2Votes) OR (ID2 = @CarId AND ID2Votes > ID1Votes) AND challenges.ID1 IN (SELECT gallerier.ID FROM gallerier WHERE gallerier.aktiv = 1 AND gallerier.acceptVote = 1) AND challenges.ID2 IN (SELECT gallerier.ID FROM gallerier WHERE gallerier.aktiv = 1 AND gallerier.acceptVote = 1)
Den anden:
SELECT @iNumChallWon=count(ChallengeID) FROM Challenges WHERE ID2Accept = 1 AND EndDate < getdate() AND ( (ID1Votes > ID2Votes AND challenges.ID1 IN (SELECT gallerier.ID FROM gallerier WHERE gallerier.aktiv = 1 AND acceptVote = 1 AND userID = @UserSeesion) AND challenges.ID2 IN (SELECT gallerier.ID FROM gallerier WHERE gallerier.aktiv = 1 AND acceptVote = 1)) OR (ID2Votes > ID1Votes AND challenges.ID2 IN (SELECT gallerier.ID FROM gallerier WHERE gallerier.aktiv = 1 AND acceptVote = 1 AND userID = @UserSeesion) AND challenges.ID1 IN (SELECT gallerier.ID FROM gallerier WHERE gallerier.aktiv = 1 AND acceptVote = 1)) )
De queries er ikke nemme at tune da du bruger både "større end", "mindre end" og "OR" samt IN.
Du kan checke artikelsektionen, der har jeg en række artikler om hvordan man tuner sin sql, og hvad man skal passe på med.
Grundlæggende med ovenstående: Undgå brugen af IN () - brug i stedet EXISTS () Sørg for non-clustered indeks på alle kolonner som indgår i where betingelser og join kriterier. Sørg for non-clustered indeks på kolonner som du laver COUNT på.
Hvis fx ENDDATE kolonnerne altid udfyldes ved INSERT og ikke senere opdateres, så er det en god kandidat til en clustered indeks - ellers non-clustered.
Du kan også prøve at starte INDEKS TUNING WIZARD - den finder du i Query Analyzer. Du fjerner lige variablerne (indsæt konstant for @USERSESSION og fjern ref til @iNumChallWon) og kører queryen via ITW og ser hvad den foreslår.
Men vær forsigtig med ITW - den tuner så KUN efter den ene query, så tag dens forslag med et gran salt og lav ikke et CLUSTERED indeks på en kolonne hvor værdien ændres selvom ITW foreslår det.
Jeg har fået på fornemmelsen at det ville hjælpe meget at indexere nogle af mine tabelfelter, men jeg er ikke helt med på hvordan man egentlig gør det. Har du mulighed for at skrive hvordan man gør rent praktiskt punkt for punkt? Synes nemlig det virker ret forvirrende.
Der er ikke noget trylleri involveret. Nemmest at forklare er hvordan du skriver et indeks i rå sql - men du kan også oprette indeks via Enterprise Manager.
Men i SQL syntax:
create index [mytable_myindex] on [mytable] (column,,,,)
dvs hvis du skal have et indeks på aktiv i tabellen gallerier kan du gøre således
create index [ix_gallerier_aktiv] on [gallerier](aktiv)
Du kan godt samle flere kolonner i et enkelt indeks - men det er ikke altid det er en fordel, og det er altid en vurdering hvilken kolonne der skal først.
create index [ix_gallerier_aktivaccept] on [gallerier](aktiv,acceptvote)
Jeg vil igen henvise til mine artikler om indeks i artikel sektionen - der er det lidt mere uddybende forklaret.
Husk at jo flere indeks, jo mere belastning af server ved indsættelse / opdatering - altså ikke flere indeks end du har behov for.
Synes godt om
Ny brugerNybegynder
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.