Uopšteno govoreći, optimizacija SQL-a teži minimiziranju broja koraka – “dodira baze podataka” – koje upit podrazumeva, čime se smanjuje vreme obrade i vreme čekanja. Postoji mnogo sitnih SQL trikova i najboljih praksi koje treba imati na umu, i iako ova lista ni na koji način nije sveobuhvatna ili univerzalno primjenjiva, sledeće smernice su korisne u velikom broju situacija.
- Optimizaciju je potrebno otpočeti identifikovanjem najskupljih upita kako bi se adekvatno rasporedili napori optimizacije. Istina je da je optimizacija performansi SQL upita kontinuirani proces; uvek postoji prostor za poboljšanje, uvek ima više koda za optimizaciju, i uvek je potrebno nadgledanje i održavanje – što može dovesti do osećaja da se nikada ne završava. Iz tog razloga, važno je izolovati SQL izjave visokog uticaja – one koje se najčešće izvršavaju i zahtevaju najviše aktivnosti baze podataka i I/O operacija (operacije čitanja i pisanja). Ove izjave pružaju najveće povraćaje u poboljšanju performansi baze podataka, pa njihovo ciljanje optimizuje količinu uloženog rada u odnosu na poboljšanje performansi.
- Kada god je moguće, minimizovati količinu podataka koja mora biti skenirana u operaciji. Mnoge SQL izjave će podstaći bazu podataka da izvrši skeniranje cele tabele, što nosi mnogo veći broj I/O operacija i može smanjiti performanse usporavanjem operacija i izvođenjem nepotrebno “širokih” pretraga. Da bi se optimizovalo dobijanje podataka, preporučuje se:
- Dodati indekse tabelama ako treba da se pristupi manje od 5% njihovih podataka, osim u slučaju prilično malih tabela (koje se efikasnije pretražuju u potpunosti bez obzira na to da li je potrebno mnogo podataka).
- Ne uključivati * u SELECT izjavama osim ako je neophodno za dobijanje podataka, jer ovaj simbol opterećuje sistem.
- Koristiti filtere u WHERE klauzulama radi ograničenja veličine skupa podataka.
- Nasuprot tome, u sistemu orijentisanom ka kolonama, odabrati samo kolone koje su potrebne za upit.
- Ukloniti nepotrebne tabele iz SQL izjava. Ponekad programeri zaborave da uklone JOIN-ove koji ne služe upitu a koristili su za testiranje upita. Iako to može biti bezopasno u fazi testiranja, JOIN-ovi na tabelama koje ne doprinose dobijanju podataka mogu znatno povećati vreme obrade.
- Koristiti EXISTS u podupitima. To govoru SUBP-u da može da zaustavi pretragu kada pronađe podudaranje, umesto da izvrši skeniranje cele tabele.
- Ne koristiti indekse na tabelama koje prolaze kroz više UPDATE ili INSERT operacija, jer indeksi mogu usporiti unos podataka. U istom duhu, možda trebalo bi razmotriti brisanje indeksa kada se teži grupnim ažuriranjima ili unosima. U ovom slučaju, možda je najbolje ponovo kreirati indekse nakon jednog događaja u grupi ili jednostavno izbeći indekse na tabelama koje često doživljavaju unos podataka u grupama.
- Ne mešati tipove podataka, i ne konvertujtovati brojeve u znakove. Njihovo poređenje može usporiti operacije i uticati na performanse.
- U nekim scenarijima, možda je lakše kreirati novo polje nego izvršiti funkciju izračunavanja na JOIN ili WHERE klauzuli. U ovom slučaju, novo polje bi sadržalo izračunatu vrednost, koju bi izjava odabrala umesto da je sama izračuna. Da biste to postigli, osoba koja optimizuje kod mora imati dozvolu da menja skupove podataka, naravno – ali to ne bi trebalo da predstavlja problem za DBA ili drugog IT administratora.
- Šire gledano, potreno je uskladiti svoje SQL izjave i skupove podataka. U osnovi, potrebno je proveriti SQL sintaksu kako bi se proverilo da li su SQL izjave napisane na načine koji se podudaraju sa strukturom podataka i omogućavaju lagan pristup.
- Uvesti protokol korišćenjem procedura umesto pojedinačnih izjava. Procedura je skup izjava, i one smanjuju troškove izvršenja ponavljajućeg upita. Na primer, ako se koristi aplikacija koja zahteva da se podaci iščitaju nedeljno, ovaj upit može činiti značajan deo aktivnosti baze podataka. Mogla bi se koristiti procedura da se osigura brzo izvršavanje uptia, i prema ručno napisanom planu izvršenja, jer baze podataka izvršavaju procedure bez optimizacije.
- Koristiti globalne privremene tabele (GTT) kad god je to moguće kako bi se pojednostavili komplikovani upiti za agregaciju. Razbijajući rad intenzivnih podupita, GTT su pokazale da značajno poboljšavaju performanse baze podataka.
- Koristiti sugestije. Neki SUBP-ovi pružaju listu sugestija na mreži kako bi pomogao dizajnerima aplikacija i DBA-ima. Svrha je da omogući administratorima i developerima da “izmene planove izvršenja” i “prisile različite pristupe”. To omogućava dizajnerima koji optimizuju svoje SQL izjave da preuzmu kontrolu od optimizatora u određenim scenarijima gde ljudi znaju više o podacima od optimizatora. U tim situacijama, oni mogu osigurati da se njihov plan izvršenja sprovede umesto da ga prepiše optimizator, koji bi mogao izabrati pristup pristupu podacima koji ne optimizira brzinu i performanse.
- Na kraju, učiniti optimizaciju rutinskom. Optimizacija performansi u SQL-u zahteva redovno održavanje kako bi se sprečilo pogoršanje performansi baze podataka tokom vremena kako se i skupovi podataka i RDBMS softver razvijaju. Imajući to u vidu, potrebno je obavezati se na redovno normalizovanje i defragmentaciju baze podataka.