Optymalizacja
pachu - 22-05-2006 00:01
Optymalizacja
Hello,
Poszukuje materialow w sieci dotyczacych optymalizacji zapytan SQL -
owych badz zaawansowanego SQL -a. Wiekszosc tutoriali niestety jest na
poziomie prostych selectow ... Jakies sugestie ??
--
pachu
=?ISO-8859-2?Q?Micha=B3?= Kuratczyk - 23-05-2006 00:24
pachu wrote:
> Poszukuje materialow w sieci dotyczacych optymalizacji zapytan SQL -
> owych badz zaawansowanego SQL -a. Wiekszosc tutoriali niestety jest na
> poziomie prostych selectow ... Jakies sugestie ??
Żeby pisać wydajne SQLe musisz po prostu wiedzieć jak działa Twoja baza,
jakie funkcje/mechanizmy oferuje i jak porównywać wydajność różnych
rozwiązań. Czyli generalnie dokumentacja Twojej bazy - przede wszystkim SQL
reference oraz wszystko o dostępnych rodzajach
tabel/indeksów/widoków/klastrów/planów/itd, ale im więcej dokumentacji
wchłoniesz tym lepiej.
--
Michał Kuratczyk
Bastion - 24-05-2006 00:18
Użytkownik "Michał Kuratczyk" <kura@lj.pl> napisał w wiadomości
news:e4rtik$2e2$3@abg.com.pl...
> Żeby pisać wydajne SQLe musisz po prostu wiedzieć jak działa Twoja baza,
> jakie funkcje/mechanizmy oferuje i jak porównywać wydajność różnych
> rozwiązań. Czyli generalnie dokumentacja Twojej bazy - przede wszystkim SQL
> reference oraz wszystko o dostępnych rodzajach
> tabel/indeksów/widoków/klastrów/planów/itd, ale im więcej dokumentacji
> wchłoniesz tym lepiej.
Chyba troche przesadzasz? Jasne ze teoria jest wazna ale mozna przeciez
po prostu przetestowac szybkosc zapytan. Lepsze bazy maja specjalne
profilery pozwalajace sprawdzac ilosc wywolan poszczegolnych procedur
wbudowanych,
triggerow, eventow, czas wykonania poszczegolnych zapytan, itp.
Druga sprawa, przeciez zawsze mozna, testowane zapytanie,
odpalic je z poziomu jezyka wyzszego poziomu:
//BCB
void __fastcall TForm1::Button1Click(TObject *Sender)
{ DWORD start;
start=GetTickCount();
Query1->Close();
Query1->SQL=Memo1->Lines;
for(int i=0;i<CSpinEdit1->Value;i++)
Query1->ExecSQL();
ShowMessage("Czas wykonania: "+IntToStr(GetTickCount()-start)+" ms");
Screen->Cursor=crDefault;
}
Wracajac do wydajnosci zapytan, z moich doswiadczen wynika:
1) Nad optymalnoscia, szybkoscia zapytan trzeba pomyslec juz
na poziomie projektowania bazy.
2) Wszelkie join-y sa wyjatkowo wolne.
3) W gotowej bazie, jezeli czynnikiem krytycznym nie
jest objetosc bazy to... indeksowac, indeksowac, indeksowac;)
4) Oczywiscie (o czym pisales) help i studiowanie hasla "optimizer" i
"optimizations".
Pozdrawiam
=?ISO-8859-2?Q?Micha=B3?= Kuratczyk - 25-05-2006 00:49
Bastion wrote:
>> Żeby pisać wydajne SQLe musisz po prostu wiedzieć jak działa Twoja baza,
>> jakie funkcje/mechanizmy oferuje i jak porównywać wydajność różnych
>> rozwiązań. Czyli generalnie dokumentacja Twojej bazy - przede wszystkim
>> SQL reference oraz wszystko o dostępnych rodzajach
>> tabel/indeksów/widoków/klastrów/planów/itd, ale im więcej dokumentacji
>> wchłoniesz tym lepiej.
> Chyba troche przesadzasz?
Piszesz, że przesadzam, a potem powtarzać praktycznie to samo. :-)
> Jasne ze teoria jest wazna ale mozna przeciez
> po prostu przetestowac szybkosc zapytan.
Ale trzeba wiedzieć jak przerobić zapytanie - jak inaczej można uzyskać ten
sam wynik, żeby porównać która metoda jest lepsza (często nie trzeba tego
nawet odpalać - przy odrobinie doświadczenia wiele przypadków jest
oczywistych). Dlatego napisałem "musisz wiedzieć (...) jakie
funkcje/mechanizmy oferuje".
> Lepsze bazy maja specjalne profilery pozwalajace sprawdzac ilosc wywolan
> poszczegolnych procedur wbudowanych, triggerow, eventow, czas wykonania
> poszczegolnych zapytan, itp.
Dlatego napisałem "musisz wiedzieć (...) jak porównywać wydajność różnych
rozwiązań". Jak już mamy kilka wersji, to jak sprawdzić która jest lepsza.
Te same / podobne narzędzia stosuje się też, żeby znaleźć co powoduje wolne
działanie systemu (wąskie gardła).
> Druga sprawa, przeciez zawsze mozna, testowane zapytanie,
> odpalic je z poziomu jezyka wyzszego poziomu:
Można, tylko po co. :->
Więcej roboty, a w dodatku dodajesz nowe elementy, które mogą wpłynąć na
wynik porównania.
> 1) Nad optymalnoscia, szybkoscia zapytan trzeba pomyslec juz
> na poziomie projektowania bazy.
Oczywiście. Dlatego napisałem "wszystko o dostępnych rodzajach
tabel/indeksów/widoków/klastrów/planów/itd". Projektując strukturę bazy
zapewniamy sobie (lub nie) możliwość pisania wydajnych zapytań na niej
operujących. Jak system już działa (a to jest moment kiedy wiele osób
zaczyna dopiero optymalizację), to zmiana czegokolwiek jest znacznie
trudniejsza.
> 2) Wszelkie join-y sa wyjatkowo wolne.
Tu się zupełnie nie zgodzę. Bazy danych są stworzone do robienia joinów.
Albo używasz kiepskiej bazy, albo używasz jej źle. Może jakiś przykład?
> 3) W gotowej bazie, jezeli czynnikiem krytycznym nie
> jest objetosc bazy to... indeksowac, indeksowac, indeksowac;)
Objętość to pół biedy. Przede wszysktim krytycznym czynnikiem nie może być
czas zapisów do bazy, które z powodu indeksów trwają znacznie dłużej.
Strategia "indeksować, indeksować, indeksować", to głównie hurtownie danych,
gdzie zapisów praktycznie nie ma. No i nawet indeksując na potęgę, to
jeszcze trzeba wiedzieć jak (indeksy zwykłe czy bitmapowe, na pojedynczej
kolumnie czy na wielu, itd). Żeby wiedzieć jak indeksować, to trzeba
wiedzieć jak działa baza (z jakich indeksów w jakich sytuacjach skorzysta,
a w jakich nie). Np. co z tego, że na każdej kolumnie założysz indeks,
jeśli w każdej kolumnie dowolna wartość wybiera powiedzmy 10% danych? Jest
duża szansa, że baza w ogóle nie skorzysta z żadnego z tych indeksów. Ale
jeśli wiesz, że zapytania zwykle wybierają konkretną wartość kolumn
A, B i C, a kombinacja tych trzech wartości wybiera 0.1% danych z tabeli, to
baza z przjemnością będzie korzystać z pojedynczego indeksu na tych trzech
kolumnach.
--
Michał Kuratczyk
Bastion - 25-05-2006 00:50
Użytkownik "Michał Kuratczyk" <kura@lj.pl> napisał w wiadomości
news:e513tm$7rk$1@abg.com.pl...
> Bastion wrote:
> Piszesz, że przesadzam, a potem powtarzać praktycznie to samo. :-)
W pierwszym poscie polozyles caly nacisk na wiedze teoretyczna.
W mojej skromnej wypowiedzi staralem sie polozyc akcent na
mozliwosci praktycznego testowania, optymalizowania SQL-a.
> Ale trzeba wiedzieć jak przerobić zapytanie - jak inaczej można uzyskać ten
> sam wynik, żeby porównać która metoda jest lepsza (często nie trzeba tego
> nawet odpalać - przy odrobinie doświadczenia wiele przypadków jest
> oczywistych). Dlatego napisałem "musisz wiedzieć (...) jakie
> funkcje/mechanizmy oferuje".
Sprobuj zoptymalizowac procedure wbudowana liczaca 500- 1000 linijek kodu SQL,
bez pomocy narzedzi profilujacych lub prostych sztuczek programistycznych
(obliczanie czasu wykonania z poziomu jezyka wyzszego poziomu).
> Dlatego napisałem "musisz wiedzieć (...) jak porównywać wydajność różnych
> rozwiązań". Jak już mamy kilka wersji, to jak sprawdzić która jest lepsza.
> Te same / podobne narzędzia stosuje się też, żeby znaleźć co powoduje wolne
> działanie systemu (wąskie gardła).
Szkoda, ze nie napisales o tym tak wyraznie w pierwszym poscie,
nie byloby zadnej dyskusji.
> > 2) Wszelkie join-y sa wyjatkowo wolne.
> Tu się zupełnie nie zgodzę. Bazy danych są stworzone do robienia joinów.
> Albo używasz kiepskiej bazy, albo używasz jej źle. Może jakiś przykład?
Zrob selecta z 1,5-cioma, 10-oma join-ami na nieideksowanej tablicach liczacych
po 100000 -1000000 rekordow:)
> > 3) W gotowej bazie, jezeli czynnikiem krytycznym nie
> > jest objetosc bazy to... indeksowac, indeksowac, indeksowac;)
> Objętość to pół biedy.
Tutaj sie zgadzam, piszesz o rzeczach oczywistych;)
Pozdrawiam
=?ISO-8859-2?Q?Micha=B3?= Kuratczyk - 26-05-2006 01:43
Bastion wrote:
> W pierwszym poscie polozyles caly nacisk na wiedze teoretyczna.
Bo jeśli chodzi o optymalizację zapytań, to moim zdaniem jest niezbędna.
Wiadomo, że sama teoria to za mało, ale jeśli nie wiesz, że istnieje jakiś
mechanizm, to go nie użyjesz. A może to właśnie jego użycie spowodowałoby
olbrzymi wzrost wydajności (np. in-line view zamiast skorelowanego
podzapytania).
> Sprobuj zoptymalizowac procedure wbudowana liczaca 500- 1000 linijek kodu
> SQL, bez pomocy narzedzi profilujacych lub prostych sztuczek
> programistycznych (obliczanie czasu wykonania z poziomu jezyka wyzszego
> poziomu).
Nie używam języków wyższego poziomu przy testach/optymalizacji. Nie wiem jak
inne bazy, ale Oracle zapewnia w tym temacie niesamowite możliwości na
poziomie PL/SQLa.
>> > 2) Wszelkie join-y sa wyjatkowo wolne.
>> Tu się zupełnie nie zgodzę. Bazy danych są stworzone do robienia joinów.
>> Albo używasz kiepskiej bazy, albo używasz jej źle. Może jakiś przykład?
> Zrob selecta z 1,5-cioma, 10-oma join-ami na nieideksowanej tablicach
> liczacych po 100000 -1000000 rekordow:)
To tak jakbyś powiedział "samochody nie potrafią szybko pokonywać wzniesień;
jak nie wierzysz, to spróbuj jechać tyłem pod oblodzoną górkę na oponach
typu slick". :->
--
Michał Kuratczyk
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
pobranie danych z 3 tabel
CD
licznik sciągnięć
[Oracle] SID i port bazy
"PHOTOSHOP I GRAFIKA BITMAPOWA "
problemy z logowaniem si? do bazy danych
Format CSV
z LATIN2 na UTF8
Certyfikat Oracle
[photoshop] Fatalne zdjecia - co z nimi zrobic
zanotowane.pldoc.pisz.plpdf.pisz.pllatwa-kasiora.pev.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
