Hier is de handige lijst met dingen die ik altijd geef aan iemand die me vraagt naar optimalisatie.
We gebruiken voornamelijk Sybase, maar de meeste adviezen zullen over de hele linie van toepassing zijn.
SQL Server wordt bijvoorbeeld geleverd met een groot aantal prestatiebewakings- / afstemmingsbits, maar als je zoiets niet hebt (en misschien zelfs als je dat wel hebt), zou ik het volgende overwegen...
99% van de problemen Ik heb gezien dat deze worden veroorzaakt door te veel tabellen in een join . De oplossing hiervoor is om de helft van de join te doen (met sommige tabellen) en de resultaten in een tijdelijke tabel te cachen. Voer vervolgens de rest van de query uit op die tijdelijke tabel.
Controlelijst voor query-optimalisatie
- Voer UPDATE STATISTICS uit op de onderliggende tabellen
- Veel systemen voeren dit uit als een geplande wekelijkse taak
- Records uit onderliggende tabellen verwijderen (eventueel de verwijderde records archiveren)
- Overweeg om dit automatisch één keer per dag of één keer per week te doen.
- Indexen opnieuw opbouwen
- Tabellen opnieuw opbouwen (bcp-gegevens uit/in)
- Dump / herlaad de database (drastisch, maar kan corruptie verhelpen)
- Nieuwe, meer geschikte index maken
- Voer DBCC uit om te zien of de database mogelijk beschadigd is
- Sloten / Deadlocks
- Zorg ervoor dat er geen andere processen in de database worden uitgevoerd
- Vooral DBCC
- Gebruik je vergrendeling op rij- of paginaniveau?
- Vergrendel de tabellen exclusief voordat u de zoekopdracht start
- Controleer of alle processen tabellen in dezelfde volgorde benaderen
- Zorg ervoor dat er geen andere processen in de database worden uitgevoerd
- Worden indexen op de juiste manier gebruikt?
- Joins gebruiken alleen index als beide expressies exact hetzelfde gegevenstype hebben
- Index wordt alleen gebruikt als de eerste veld(en) in de index overeenkomen in de zoekopdracht
- Worden geclusterde indices gebruikt waar van toepassing?
- bereikgegevens
- WAAR-veld tussen waarde1 en waarde2
- Kleine joins zijn leuke joins
- Standaard houdt de optimizer alleen rekening met de tabellen met 4 tegelijk.
- Dit betekent dat het bij joins met meer dan 4 tabellen een goede kans heeft om een niet-optimaal queryplan te kiezen
- Verbreek de samenkomst
- Kun je de join verbreken?
- Preselecteer externe sleutels vooraf in een tijdelijke tabel
- Doe de helft van de join en plaats de resultaten in een tijdelijke tabel
- Gebruik je de juiste soort tijdelijke tabel?
#temptabellen kunnen veel beter presteren dan@tablevariabelen met grote volumes (duizenden rijen).
- Overzichtstabellen bijhouden
- Bouw met triggers op de onderliggende tabellen
- Bouw dagelijks / elk uur / etc.
- Ad-hoc bouwen
- Incrementeel bouwen of afbreken / opnieuw opbouwen
- Bekijk wat het zoekplan is met SET SHOWPLAN ON
- Zie wat er werkelijk gebeurt met SET STATS IO ON
- Een index forceren met behulp van het pragma:(index:myindex)
- Forceer de tabelvolgorde met SET FORCEPLAN ON
- Parameter snuiven:
- Opgeslagen procedure in 2 delen
- bel proc2 vanuit proc1
- staat de optimiser toe om index te kiezen in proc2 als @parameter is gewijzigd door proc1
- Kunt u uw hardware verbeteren?
- Hoe laat loop je? Is er een rustiger moment?
- Is Replication Server (of een ander non-stop proces) actief? Kun je het opschorten? Voer het bijv. per uur?