Ik neem ook aan dat je Oracle gebruikt. En ik raad je ook aan om de webpagina 'plan uitleggen' te bekijken, om te beginnen. Er komt veel kijken bij optimalisatie, maar het kan worden geleerd.
Een paar tips volgen:
Ten eerste, wanneer iemand je de opdracht geeft om te optimaliseren, zijn ze bijna altijd op zoek naar acceptabele prestaties in plaats van ultieme prestaties. Als je de doorlooptijd van een zoekopdracht kunt verkorten van 3 minuten tot 3 seconden, maak je dan geen zorgen om deze terug te brengen tot 2 seconden, totdat je hierom wordt gevraagd.
Ten tweede, voer een snelle controle uit om er zeker van te zijn dat de query's die u optimaliseert logisch correct zijn. Het klinkt absurd, maar ik kan je niet vertellen hoe vaak ik om advies ben gevraagd over een langzaam lopende vraag, alleen om erachter te komen dat het af en toe verkeerde antwoorden gaf! En het bleek dat het debuggen van de query vaak ook sneller bleek te zijn.
Zoek in het bijzonder naar de uitdrukking "Cartesian Join" in het uitlegplan. Als je het daar ziet, is de kans erg groot dat je een onbedoelde cartesiaanse join hebt gevonden. Het gebruikelijke patroon voor een onbedoelde cartesische join is dat de FROM-component tabellen bevat, gescheiden door komma's, en dat de join-voorwaarden in de WHERE-component staan. Behalve dat een van de join-voorwaarden ontbreekt, zodat Oracle geen andere keuze heeft dan een cartesiaanse join uit te voeren. Met grote tabellen is dit een prestatieramp.
Het is mogelijk om een Cartesian Join te zien in het explain plan waar de query logisch correct is, maar ik associeer dit met oudere versies van Oracle.
Zoek ook naar de ongebruikte samengestelde index. Als de eerste kolom van een samengestelde index niet wordt gebruikt in de query, kan Oracle de index inefficiënt of helemaal niet gebruiken. Laat me een voorbeeld geven:
De vraag was:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(De DBMS was geen Oracle, dus de syntaxis was anders, en ik ben de originele syntaxis vergeten).
Een snelle blik op de indexen onthulde een index op Klanten met de kolommen (Land, Staat, Postcode) in die volgorde. Ik heb de zoekopdracht gewijzigd om te lezen
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
en nu liep het in ongeveer 6 seconden in plaats van ongeveer 6 minuten, omdat de optimizer de index goed kon gebruiken. Ik vroeg de applicatieprogrammeurs waarom ze het land uit de criteria hadden weggelaten, en dit was hun antwoord:ze wisten dat alle adressen een land hadden dat gelijk was aan 'VS', dus ze dachten dat ze de zoekopdracht konden versnellen door dat criterium weg te laten!
Helaas is het optimaliseren van het ophalen van databases niet echt hetzelfde als het schrappen van microseconden van rekentijd. Het gaat om inzicht in het databaseontwerp, met name indexen, en op zijn minst een overzicht van hoe de optimizer zijn werk doet.
Over het algemeen krijg je betere resultaten van de optimizer als je ermee leert samenwerken in plaats van te proberen hem te slim af te zijn.
Veel succes om op snelheid te komen met optimalisatie!