[SQL Server 2000] Rare performance

[Verwijderd]

Intro
Ik moet wat data voor een grafiek berekenen. Dit doe ik met een aantal queries. Deze queries zien er hetzelfde uit, maar hebben telkens een andere datumrange. Het is dus erg belangrijk dat de performance van deze queries optimaal is. Vandaar mijn vraag...


Ik heb de volgende query:

SQL:

SELECT COUNT([id])
FROM verschillen
WHERE FileimportTimestamp BETWEEN '01-01-2008' AND '01-07-2008'

Deze geeft als count ongeveer 14000 terug. Prima.
Hij berekent dit is ongeveer 10 miliseconden. Goed.

Nu ga ik deze query uitbreiden:

SQL:

SELECT COUNT([id])
FROM verschillen
WHERE FileimportTimestamp BETWEEN '01-01-2008' AND '01-07-2008'
AND Afgehandeld = 1

Deze geeft als count ongeveer 7000 terug. Prima.
Maar nu doet de query er ineens 90 miliseconden over. Erg vervelend.

Ik snap eerlijk gezegd niet waarom deze query (of beter gezegd: deze extra voorwaarde) de boel ineens zo vertaagd. Het veld Afgehandeld is van het type Bit. Ik heb de indexen gecontroleerd, maar een index op een Bit veld vertraagt alleen maar, dus die heb ik er weer afgehaald. Ik heb de volgorde in de where-clausule aangepast, maar dat scheelt ook niks.

Ben ik gedoemd met eent trage query, of zie ik iets over het hoofd?

Toevoeging
Je denkt misschien, wat een gezeur om 80 miliseconden, maar ik moet 24 waardes op deze manier opvragen. Omdat ik de grafiek real-time wil opbouwen, moet de performance optimaal zijn. Met nog wat bijkomende berekeningen etc. ben ik drie seconden aan het wachten op een grafiek, en dat is te lang.

[pedorus]

Heb je ook een gecombineerde index op bit,FileimportTimestamp?
24x een query kan niet ook met group by?

[Verwijderd]

Wow!

Ik gecombineerde index is inderdaad de oplossing Pedorus.

Simpel testje met 12 queries: querytijd gaat terug van 910 miliseconden naar 50 miliseconden!!

[_Thanatos_]

Als je al die berkeningen achter elkaar zet in een stored proc, of ze weet te combineren tot 1 query (of een combinatie van deze suggesties), zou je nog weleens veel meer snelheidswinst kunnen halen.

Een stored proc wordt nog es een soort van gecompileerd, waardoor de queries niet meer geparsed hoeven te worden. En het voordeel van minder losse queries lijkt me evident.

[RobIII]

_Thanatos_ schreef op vrijdag 01 augustus 2008 @ 16:46:
Een stored proc wordt nog es een soort van gecompileerd, waardoor de queries niet meer geparsed hoeven te worden. En het voordeel van minder losse queries lijkt me evident.

Maar de winst zit 'm in dit geval echt wel in de juiste indices. Het parsen van de query is in zo'n geval pretty verwaarloosbaar en op zo'n 'bak' data ga je dat kleine beetje overhead echt niet merken.

[Fiander]

waarom doe je eigenlijks een count op het ID veld ?
het lijkt mij dat je nu SQL Server dwingt om juist die kolom te tellen.

probeer eens om het datumtijd veld te gebruiken in de count. het lijkt mij dat je dan de query in zijn geheel in de index kunt afhandelen, en je ook geen locks meer op je tabel krijgt.


bovenstaande klopt uiteraard niet als ID een geclusterde index is.

[Verwijderd]

ID is al een geclusterde index is.

Ik ga in ieder geval een testje uitvoeren met jouw suggestie.

[whoami]

Als dat datumveld nooit veranderd, en altijd 'incrementeel' groeit (maw, als de records die je toevoegt altijd een hogere datum/tijd hebben dan het vorige ge-inserte record), en die datum uniek is (alhoewel dat in principe geen voorwaarde is van een clustered query), dan zou ik er sterk over nadenken om die clustered index van 'ID' weg te halen (die toch geen zin heeft, behalve dan om er voor te zorgen dat jouw table geen heap is), en 'm op die datum te plaatsen ...
Daar ga je nog wat snelheidswinst uithalen. SQL Server hoeft dan enkel maar het eerste record op te zoeken, en dan weet hij dat alle andere records die je nodig hebt, er allemaal voor (of allemaal achter) liggen.

Wat Fiander zegt kan ook veel schelen, aangezien je dan een volledige 'covered query' hebt.

[Fiander]

@Whoami
als ID de voledige clusterd index is, dan zit hij automatisch ook in elke andere index als key opgenomen en heb je dus al een covered index.


bij dit soort queries gebruik ik zelf altijd een * in de count.
daarmee zeg je dat het je niet uitmaakt welke kolom SQLServer gebruikt om te tellen, en zal die waar mogelijk het uit de index halen.