[es] - Firebird - kako postići brzinu?

delalt

Član broj: 68360
Poruke: 198
*.teol.net.

Profil

^{16.06.2006. u 11:04 - pre 230 meseci}

Ne bi bilo loše malo diskutovati i o brzini Firebirda,
šta sve utiče na brzinu izvršavanja SQL upita, i kako
što bolje riješiti ove probleme.

Znam da se ove stvari rješavaju drugačije od slučaja do slučaja,
ali postoje i neke generalne stvari koje vrijede gotovo uvijek.
Najprostiji primjer je kad nije kreiran index po nekoj koloni
koja se koristi u JOIN-u.
Takav upit (u zavisnosti od broja zapisa) može da traje satima, izgleda
kao da se neće ni izvršiti i zauzima dosta resursa.
Ne mijenjajući upit (koji je u principu i dobar) i samo prostim
kreiranjem index-a po toj koloni, rezultati se drastično mijenjaju i
upit se izvršava veoma brzo (u par sekundi ili minuta, opet zavisno od broja
zapisa).
Razlog ovome je što Firebird ne kreira automatski index-e, već ih samo
koristi ako već postoje. Ovo, čini mi se, vrijedi i za Firebird 2.0 iako se
napominje da je brži u radu od verzije 1.5.
Evo jedan link koji govori o optimizaciji, korištenju PLAN-a...

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_quep

E, sad, vaša iskustva, gdje ste najviše dobili na brzini (bilo kako,
npr. koristeći druge komponente za rad sa Firebird-om,
koliko utiče korištenje UDF,
na šta treba najviše obratiti pažnju kod samog dizajna baze...).

Naravno, ako neko zna kakve dobre knjige, tutorijale i primjere
za optimizaciju upita, u elektronskom formatu, slobodno neka da linkove.

Odgovor na temu

schild
Dejan Šild
TopCode Software
Subotica

Član broj: 59888
Poruke: 138
*.legendww.com.

Sajt: www.topcode.rs

+2 Profil

Re: Firebird - kako postići brzinu?

^{19.06.2006. u 06:44 - pre 230 meseci}

Moje iskustvo sa FB 1.5 je da treba izbegavati LEFT/RIGHT JOIN koliko je moguce, bez obzira na indexe, jer drasticno usporava upit.
INNER JOIN radi ok, podrazumeva se da imas index na koloni koju koristis, ali ako koristis FK, onda imas index.
Umesto L/R JOIN mozes koristiti umetnute upite tipa [select a,b, (select c from tt where ...) as nesto, d from ttttt].
Ostale stvari se mogu eventualno optimizovati koriscenjem procedura.

Jos jedan tip: primetio sam da neki put PLAN optimizer koristi NATURAL index umesto PRIMARY.
Ako dodas:
SELECT ...
...
WHERE PK_FIELD > ''

plan ce koristiti PK!
(PK_FIELD je polje koje je PK u tabeli)

Odgovor na temu