Profilowanie aplikacji |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
Profilowanie aplikacji |
3.10.2007, 11:52:58
Post
#21
|
|
Grupa: Zarejestrowani Postów: 53 Pomógł: 0 Dołączył: 16.11.2004 Ostrzeżenie: (0%) |
Właśnie - bardzo często problemem jest wydajność bazy danych, nie samego PHP.
Wydajność bazy można poprawić na co najmniej 2 sposoby: 1. dobrze indeksować dane (większość programistów ma z tym problemy) 2. buforować dane w pamięci Odnośnie punktu 1 - co byście powiedzieli, gdyby istniało narzędzie, które automatycznie dobiera właściwe indeksy na podstawie logu zapytań? Istnieje takie coś w Oracle i DB/2, a co gdyby było też coś opensource, np. dla MySQL? A może takie coś istnieje, ale nie znalazłem? -------------------- Projekty: PLAY, optymalizator baz danych
|
|
|
3.10.2007, 12:04:13
Post
#22
|
|
Grupa: Zarejestrowani Postów: 2 262 Pomógł: 21 Dołączył: 3.05.2004 Skąd: Sopot, Krakow, W-wa Ostrzeżenie: (0%) |
Krolik - mowisz o wybieraniu sposobu indeksownia typu B-Tree itp ? W MySQLu moze byc problem z czyms takim gdyz np MyISAM obsluguje tylko B-Tree wiec duzego wyboru nie ma.
-------------------- Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
|
|
|
3.10.2007, 12:34:11
Post
#23
|
|
Grupa: Zarejestrowani Postów: 53 Pomógł: 0 Dołączył: 16.11.2004 Ostrzeżenie: (0%) |
Nie, mam na myśli generalnie dobór indeksów a nie tylko typu. Zauważ, że indeksy można zakładać na różnych tabelach i różnych kolumnach. W praktyce liczba możliwości nawet w niewielkiej bazie jest przeogromna, a większość ludzi robi to "na czuja", wcale nie podpierając tego fachowa wiedzą.
-------------------- Projekty: PLAY, optymalizator baz danych
|
|
|
3.10.2007, 20:51:55
Post
#24
|
|
Grupa: Zarejestrowani Postów: 233 Pomógł: 9 Dołączył: 3.06.2007 Ostrzeżenie: (0%) |
nie bardzo to widzę...
musiałaby to być złożona klasa która jest klasą abstrakcji bazy... i musiałaby manipulować zapytaniami bo z tego co wiem jeżeli mamy założony jakiś indeks na kilku kolumnach to liczy się kolejność ich wymienienia w zapytaniu w klauzuli WHERE wprowadzenie zatem ich w jednym zapytaniu w pewnej kolejności a w drugim odwrotnie... zmuszałoby klasę do tworzenia innego indeksu albo manipulowania zapytaniem... to raczej będzie prowadziło do wielu trudnych do wykrycia błędów zasadniczo to języki programowania są zrobione po to aby człowiek myślał i kazał wykonywać coś komputerowi optymalizacja jest zajęciem typowym dla fachowców to człowiek musi wymyślić którędy będzie najlepiej... komputer nie wymyśli algorytmów pisać klasy pomocnicze powinno się robić raczej do przyspieszenia rozwoju aplikacji, zmniejszajać ilość powtarzalnych czynności tworzenie różnorodnych indeksów w celu maksymalnego wykorzystania zasobów jest raczej pracą twórczą niż odtwórczą... |
|
|
4.10.2007, 10:53:07
Post
#25
|
|
Grupa: Zarejestrowani Postów: 53 Pomógł: 0 Dołączył: 16.11.2004 Ostrzeżenie: (0%) |
Zimi, nie pytałem, czy to się da zrobić, tylko czy coś takiego byłoby potrzebne. Sądząc po tym, co napisałeś o optymalizacji zapytań - utwierdza mnie w przekonaniu, że jest potrzebne.
Mianowicie mijasz się z prawdą twierdząc, że indeksowanie wymaga zmiany zapytań. Kolejność w WHERE może być dowolna i nie ma nic do kolejności indeksów. Systemy RDBMS, nawet te najbardziej prymitywne, traktują WHERE jako ZBIÓR warunków i kolejność występowania warunków połaczonych ANDem czy ORem nie ma znaczenia (te opreratory sa przemienne). Jedynie ma znaczenie kolejność kolumn w indeksach wielokolumnowych, ale to indeksy dobiera się do zapytań, a nie na odwrót. Odnośnie tego, że musiała by być to złożona klasa abstrakcji: i tak i nie. To że złożona, to jest oczywiste, problem prosty nie jest. Nikt nie mówił że ma być łatwo. Tyle, że to raczej cały system a nie pojedyncza klasa. No i wcale nie musi być to coś pomiędzy aplikacją PHP a bazą danych. Wystarczy osobny program, który ma dostęp do bazy danych i logów zapytań (w MySQL można go włączyć). Taki demon wspomagający pracę admina bazy. BTW: raczej nie wyobrażam sobie implementowania tego w PHP, ze względu na zbyt niską wydajność, tylko raczej w C++ lub Javie, ale to sprawa drugorzędna i dla użytkowników nie mająca większego znaczenia. Cytat optymalizacja jest zajęciem typowym dla fachowców Hehe, a kompilatory to myślałeś że co robią? A optymalizatory zapytań w RDBMS? W serwerowni siedzi człowiek i każde zapytanie SELECT ręcznie optymalizuje? Cytat komputer nie wymyśli algorytmów Wymyśli - złe słowo, ale dobierze i sparametryzuje - zdecydowanie TAK. Cytat tworzenie różnorodnych indeksów w celu maksymalnego wykorzystania zasobów jest raczej pracą twórczą niż odtwórczą Słyszałeś o uczeniu maszynowym? AI? -------------------- Projekty: PLAY, optymalizator baz danych
|
|
|
4.10.2007, 12:57:06
Post
#26
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
Jak dla mnie sam pomysł aplikacji jest bardzo dobry. Sam mam raczej małą wiedzę o działaniu baz danych i indeksy dobieram "zdroworozsądkowo" - bardzo fajnie byłoby aby jakiś program zrobiła analizę co gdzie i jak umieścić. Plus tego taki, że programista nie zawsze ma dobre rozeznanie co i jak jest obciążone w bazie - może mieć inną wizję a logi pokażą co innego. Dla przykładu używając ORM'ów czasami można się zdziwić zapytaniami jakie są generowane. Oczywiście można powiedzieć dobry programista kontroluje wszystko i wie jak działa jego system, ale z ręką na sercu ilu z was przegląda wszystko dokładnie od a do z.
Program nie ma żadnych "przekonań" na początku i całą analizę oparłby na logach. Dla początkujących i średnio zaawansowanych narzędzie wydaje mi się bardzo dobre, a i dla zaawansowanych pewnie przedstawiałoby jakąś wartość może nie jako "decydent" a bardziej jako "doradca". |
|
|
4.10.2007, 22:38:40
Post
#27
|
|
Grupa: Zarejestrowani Postów: 233 Pomógł: 9 Dołączył: 3.06.2007 Ostrzeżenie: (0%) |
Cytat Jedynie ma znaczenie kolejność kolumn w indeksach wielokolumnowych, ale to indeksy dobiera się do zapytań, a nie na odwrót. nie mam wiedzy absolutnej na temat optymalizacji zapytań... co więcej jest ona dość nikła, dopiero wydrukowałem sobie z manuala MySQL co ciekawego napisali o optymalizacji i będę sobie to powoli przyswajał więc teraz aby się upewnić czy się rozumiemy załóżmy że mamy indeks na 3 polach w kolejności a, b, c a następnie zapytanie: Kod SELECT (...) WHERE a="1" AND b="2" AND c="3" i wtedy nasz indeks będzie działał, i teraz drugie zapytanie: Kod SELECT (...) WHERE b="2" AND c="3" AND a="1" i tutaj nasz indeks już nic nie da... jeśli mam rację to: Cytat Mianowicie mijasz się z prawdą twierdząc, że indeksowanie wymaga zmiany zapytań. jednak wymaga to zmiany zapytania gdyż jedynie o ten przypadek mi chodziło... i sytuacje w której niczego nieświadomy użytkownik pomyli sobie kolejność kolumn albo nawet nie będzie wiedział że to ma znaczenie i zrobi odwrotnie "bo tak" Cytat ale to indeksy dobiera się do zapytań, a nie na odwrót w tym momencie Twój projekt staje się jedynie rozwiązaniem połowicznym... gdyż projekt robisz jak rozumiem docelowo dla amatorów którzy nie mają pojęcia o indeksacji i ogólnie optymalizacji zapytań... jeśli tak to indeksy wielokolumnowe niewątpliwie stoją już na wyższym poziomie, a generalnie idea powinna być "trudne uprościć" a nie "łatwe uprościć"(to ew. przy okazji), przy jednokolumnowych indeksach (przy ich tworzeniu) to na dobrą sprawę "widzę że przez to polę wyszukuję często dane" => "robię indeks" (no ew. jeszcze kilka reguł, ale ta w sumie najprostsza), nie ma w tym zbyt wielkiej filozofii, a przynajmniej ja (zaznaczam że mam braki w tej dziedzinie, jak się wymądrzam to przepraszam i poprawcie mnie) nie widzę w tym większej filozofii, choć przydatnym narzędziem będą logi zapytań, ile czasu zajmuje zapytanie, tudzież stosunek czasu do ilości rekordów w tabeli bądź inne statystyki i analiza zapytania na poziomie abstrakcji bazy aby z klauzul WHERE, ORDER BY, GROUP BY, HAVING i chyba jeszcze jakiś wydobywał nazwy kolumn i weryfikował czy na danym polu jest indeks czy nie, oczywiście niekoniecznie w momencie wykonywania każdego zapytania poza tym niezależnie od indeksów wielokolumnowych podejrzewam że optymalizacja może mieć również związek z kolejnością w klauzuli WHERE, gdyż prawdopodobnie (choć może i nie) zachodzi tam "skracanie" warunku (nie pamiętam czy miało to jakąś fachową nazwę, a jeśli tak to jaką...), a czytanie warunku zachodzi z tego co wiem od lewej do prawej chodzi o to że jeśli będziemy mieli np. Kod SELECT ... WHERE 1=0 AND (inne warunki) 1=0 oczywiście nie ma być docelowym warunkiem, chodzi mi o to że programista przy pisaniu kodu ma świadomość, że coś często będzie fałszem lub prawdą i to wstawia na "pierwsze pozycje" serwer SQL prawdopodobnie wiersz odpuści już po pierwszym warunku 1=0 gdyż z góry będzie fałszywy bezwzględu jakie wartości przybiorą kolejne zdania logiczne natomiast gdy zamienimy kolejność: Kod SELECT ... WHERE (inne warunki) AND 1=0 serwer może sporo danych przewertować, stracić dużo zasobów a i tak w końcu wyjdzie że dany wiersz nas nie interesuję... w tego typu przypadkach Twoja klasa/funkcja/program/cokolwiek nie będzie miało już wiele do gadania bo są to dość skomplikowane zagadnienia zresztą to była tylko taka dygresja o znaczeniu kolejności no ale w sumie chyba wszystko można zaprogramować Cytat A optymalizatory zapytań w RDBMS? szczerze mówiąc nie wiem, a nawet nie wiedziałem o ich istnieniu choć ich istnienie wydaję się być zrozumiałe... nie mniej podejrzewam że mają minimalne znaczenie dla efektywności zapytań, podobnie jak w kodach PHP, podobno Zend Optimizer zamienia $d++ na ++$d bo jest szybsze (nie wiem czy to prawda, tak gdzieś przeczytałem... mało ważne) jednak znaczenie takiej optymalizacji przy skopanym algrotymie jest tak nikłe że nawet niewarto o nim wspominać Cytat Słyszałeś o uczeniu maszynowym? AI? tak słyszałem, choć nie mam chwilowo pojęcia w jaki sposób działa (nie próbowałem się nawet nad tym bardziej zastanawiać), nie douczałem się w tej materii... nie mniej gdy o tym wspomniałeś odbieram wrażenie że to przerost formy nad treścią... i znacznie lepiej dla każdego kto potrzebuję optymalizacji będzie przeczytanie kilku stron o tym zagadnieniu niż skorzystaniu z takiej aplikacji, przynajmniej chwilowo taka moja opinia Cytat Plus tego taki, że programista nie zawsze ma dobre rozeznanie co i jak jest obciążone w bazie a więc potrzebujesz logów a niekoniecznie takiej aplikacji, a resztę robisz dalej "zdroworozsądkowo", a taka aplikacja może się zacząć "wymądrzać" co różne programy mają do siebie... co zaczyna być działaniem szkodliwym |
|
|
5.10.2007, 10:25:32
Post
#28
|
|
Grupa: Zarejestrowani Postów: 53 Pomógł: 0 Dołączył: 16.11.2004 Ostrzeżenie: (0%) |
załóżmy że mamy indeks na 3 polach w kolejności a, b, c a następnie zapytanie: Kod SELECT (...) WHERE a="1" AND b="2" AND c="3" i wtedy nasz indeks będzie działał, i teraz drugie zapytanie: Kod SELECT (...) WHERE b="2" AND c="3" AND a="1" i tutaj nasz indeks już nic nie da... Jeśli tak rzeczywiście jest w MySQL, to gratuluję jego twórcom lamerstwa To, że są słabi w te klocki, to wiedziałem, ale żeby aż tak, to się trzeba mocno wysilić. Dlatego niezbyt Ci wierzę Ci i jeszcze to sprawdzę. W normalnym systemie oba zapytania użyją indeksu - nie ma żadnego przeciwskazania, żeby tak nie było. Cytat abstrakcji bazy aby z klauzul WHERE, ORDER BY, GROUP BY, HAVING i chyba jeszcze jakiś wydobywał nazwy kolumn i weryfikował czy na danym polu jest indeks czy nie, oczywiście niekoniecznie w momencie wykonywania każdego zapytania Przy tym podejściu miałbyś 5 razy tyle indeksów co potrzeba. Czyli rozmiar bazy większy i niepotrzebnie spowolniony update/insert. Dalszej części postu komentował nie będę tylko polecę Ci lekturę porządnej książki o optymalizacji zapytań, konstrukcji RDBMS np. z serii Klasyka informatyki "Implementacja systemów baz danych". Mam nieodparte wrażenie, że Twoja wiedza na ten temat kłada się głównie z tego "jak myślisz, że RDBMS działa" a nie jak jest zrobiony w rzeczywistości. Poza tym wzorowanie się w tym zakresie na MySQL to zły pomysł. Cytat tak słyszałem, choć nie mam chwilowo pojęcia w jaki sposób działa (nie próbowałem się nawet nad tym bardziej zastanawiać), nie douczałem się w tej materii... Widać. Cytat nie mniej gdy o tym wspomniałeś odbieram wrażenie że to przerost formy nad treścią... i znacznie lepiej dla każdego kto potrzebuję optymalizacji będzie przeczytanie kilku stron o tym zagadnieniu niż skorzystaniu z takiej aplikacji, przynajmniej chwilowo taka moja opinia a więc potrzebujesz logów a niekoniecznie takiej aplikacji, a resztę robisz dalej "zdroworozsądkowo", a taka aplikacja może się zacząć "wymądrzać" co różne programy mają do siebie... co zaczyna być działaniem szkodliwym Ok, przyjąłem tę opinię do wiadomości. Dodam, że optymalizacja pewnej niewielkiej bazy danych (raptem 30 tabel) u nas w firmie zajęła metodą "analizy logów i EXPLAIN" jednemu wykwalifikowanemu adminowi 4 dni. Może i mało, ale należy pamiętać,że taką optymalizację robi się co jakiś czas, bo aplikacja / dane się zmieniają i że to była raptem jedna mała baza danych. A co gdybyśmy byli firmą hostingową i hostowali 100 aplikacji? Myślisz, że ktoś miałby czas bawić się i sprawdzać, czy jakiś lamer nie walnął selecta bez indeksu, który jedzie po tabeli na milion rekordów? Ten program nie ma być lepszy od wykwalifikowanego DBA, ale ma przede wszystkim zaoszczędzić czas. Podłączasz do bazy danych, wskazujesz log, klikasz jeden guzik i za 5 minut masz zestaw "prawie" optymalnych indeksów. I jeszcze takie małe, łatwe pytanie kontrolne. Jakie indeksy są najlepsze w tym przypadku: SELECT nazwa_produktu, cena, opis FROM produkty WHERE cena < 5000 AND miasto = 'Krakow' ORDER BY cena LIMIT 10; W bazie są produkty o cenach od 10 do 10000, z całego kraju. To jest klasyczne pytanie na jakie musi odpowiedzieć każdy DBA. Odpowiedź trzeba uzasadnić. -------------------- Projekty: PLAY, optymalizator baz danych
|
|
|
6.10.2007, 02:03:55
Post
#29
|
|
Grupa: Zarejestrowani Postów: 2 262 Pomógł: 21 Dołączył: 3.05.2004 Skąd: Sopot, Krakow, W-wa Ostrzeżenie: (0%) |
Krolik to pytanie dotyczy Postgres-a czy MySQLa ?
Miasta raczej bym trzymal w osobnej tabeli bo porownywanie stringow nie nalezy do najszybszych z tego co wiem. Gdyby mialo byc tak jak mowisz to na miasto nie oplacalo by sie zakladac indeksu jakoze dane powtarzaby sie. Krolik - dla MySQLa twoje pytanie nie ma sensu pozatym Bo i tak tylko zwykly index mozna zalozyc. Primay i unique odpada no chyba ze sie myle ? Co do Postgres-a moja wiedza jest obecnie niewielka tak wiec nie bede nic pisal Ale chetnie poslucham co w trawie piszczy Do do tego indeksowania po 3 polach. MySQL do wersji 5.0 korzysta tylko z jednego indeksu na danej tabeli w zapytaniu niestety Od wersji 5.0 dokonal sie postep. Aby wykorzystac indeksowanie na 3 polach czasem lepiej bylo tworzyc zapytanie korzystajac z UNION -------------------- Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
|
|
|
6.10.2007, 09:37:05
Post
#30
|
|
Grupa: Zarejestrowani Postów: 53 Pomógł: 0 Dołączył: 16.11.2004 Ostrzeżenie: (0%) |
Pytanie dotyczy dowolnego RDBMS. I nie chodzi mi tylko o jaki typ indeksu (w MySQL jest tylko B+ drzewo), ale na których (której) kolumnie. Są co najmniej 4 możliwości: tylko na cenie, tylko na mieście, 2 osobne indeksy na cenie i mieście, jeden 2-kolumnowy indeks (cena, miasto). I jeszcze zerowa możliwość: brak indeksu.
Cytat Gdyby mialo byc tak jak mowisz to na miasto nie oplacalo by sie zakladac indeksu jakoze dane powtarzaby sie Powtarzanie się danych nie jest przeciwwskazaniem dla indeksu, o ile nie jest UNIQUE. Przeciwsskazaniem może być natomiast zbyt mała selektywność warunków (czyli np. gdy się zbyt wiele powtarza) - w MyISAM niestety nie ma indeksów sklastrowanych, więc wtedy często skan sekwencyjny bywa lepszy niż użycie indeksu. Indeksy wielokolumnowe są obsługiwane w wersji zarówno 4 jak i 5 MySQL. Tylko zauważ różnicę: użycie JEDNEGO wielokolumnowego indeksu, a użycie DWÓCH różnych indeksów. MySQL 5 potrafi użyć 2 różnych indeksów i dokonać unii (jeśli był warunek OR) albo przecięcia (dla AND) - tego MySQL 4 nie potrafił. -------------------- Projekty: PLAY, optymalizator baz danych
|
|
|
15.10.2007, 17:53:02
Post
#31
|
|
Grupa: Przyjaciele php.pl Postów: 2 923 Pomógł: 9 Dołączył: 25.10.2004 Skąd: Rzeszów - studia / Warszawa - praca Ostrzeżenie: (0%) |
Padła informacja o sposobie dobierania indeksow i porownie do ORACLE. Wiec tak to odbywa sie w nastepujacy sposob, juz pomijajac sam fakt prepare i weryfikacji obiektow bazy danych. Optymalizator wylicza sobie najlpesza metode polaczenia zapytania i tytaj nie wchodzi w gre tylko i wylacznie dobor indeksow ale rowniez kolejnosc tabel w from, jakie pola beda brane pod uwage co kiedy ma robic, liczba obliczeniami zajmuje sie optymalizator w bazie ORACLE jest to od 10g kilka zmian doszlo w 11. Co do MySQLa czy PG no to wiadomo. Ogolnie wiekszosc baz wykorzystuje optymalizator regulowy.
@Krolik pisales o wilu indeksach i roznym wykorzystaniu przez MySQL5. Nieraz tak jest nieraz nie, widac to po EXPLAIN. Optymalizator to tylko zbior regul ktore ma wykonywac i na podstawie indeksow i innych obiektow podejmowac decyzje jak dane sa wyciagane. Nie wiem jak to jest z MySQLem do konca ale w takich przypadkach powinny być HINTy dla optylamizatora takie wskazówki w komentarzu jak sie ma zachować. -------------------- |
|
|
22.10.2007, 23:20:46
Post
#32
|
|
Grupa: Zarząd Postów: 2 277 Pomógł: 6 Dołączył: 27.12.2002 Skąd: Wołów/Wrocław |
@Krolik - dobre pytanie.
Niby takie proste, a jednak musiałem aż sprawdzić, by się upewnić, jak to powinno wyglądać. I niestety - już tu widać, że co baza to zwyczaj. MySQL i PG zachowują się pod tym względem bowiem nieco inaczej. W każdym z przypadków najwięcej sensu ma oczywiście index miasto, które to pole będzie zawierać najmniejszą ilość unikalnych danych. Dzięki temu też wyszukanie rekordów spełniających określonych warunek będzie bardzo szybkie. Niestety - cena jest znacznie bliższa wartości losowej, stąd też tworzenie na niej indexu w przypadku takiego zapytania nie ma zbyt wielkiej wartości, gdyż jego przeszukanie jest równoznaczne z przeszukaniem wszystkich pól w bazie, z chyba właśnie z tego powodu obie bazy nie będą chciały z niego korzystać. Co ciekawe - w przypadku PG sens może mieć index miasto_cena, który (w przypadku mojej testowej bazy - 100 tys rekordów) o połowę przyśpieszył to zapytanie (niż tylko index miasto). MySql nie potrafił skorzystać z takiego indexu w tym zapytaniu. Trzeba pamiętać jednak o tym, że będzie to naprawdę potężny index. ps. Czy naprawdę sądzisz, że automat analizujący logi jest w stanie rozwiązać takie problem za mnie? pps. Swoją drogą - jakiś mechanizm do analizy logów bazy tworzy depesz ( depesz.com ) -------------------- "Niezależnie od tego, jakie masz osiągnięcia, ktoś Ci pomaga..."
|
|
|
31.10.2007, 12:58:11
Post
#33
|
|
Grupa: Zarejestrowani Postów: 53 Pomógł: 0 Dołączył: 16.11.2004 Ostrzeżenie: (0%) |
Pytanie było specjalnie takie, żeby nie było jednoznacznej odpowiedzi. Słabsze systemy najprawdopodobniej wybiorą mniejsze zło, tj. tak jak napisał DevV:
LIMIT (1, 10) | + SORT (cena) | + INDEX_SCAN (miasto = 'Krakow' AND cena < 5000) <-- indeks na (miasto, cena) Albo tak (nieco gorzej): LIMIT (1, 10) | + SORT (cena) | + FILTER (cena < 5000) | + INDEX_SCAN (miasto = 'Krakow') <--- indeks tylko na (miasto) Wszystko zależy trochę od rozkładu wartości w bazie, ale można się spodziewać, że ponieważ Kraków jest dużym miastem, to warunek miasto = Kraków ma słabą selektywność (załóżmy 20%), podobnie warunek na cenę też ma b. słabą selektywność (ok. 50%, jeśli rozkład jest równomierny). W tej sytuacji najlepszy byłby indeks klastrujący na cena, żeby uniknąć sortowania: LIMIT(1, 10) | + FILTER (miasto = 'Krakow') | INDEX SCAN (cena < 5000) <--- indeks tylko na (cena) Niezależnie od sumarycznej liczby rekordów ten plan wymaga odczytania średnio raptem ok. 50 rekordów tabeli, ze względu na możliwość wykonania iteracyjnego i LIMIT, podczas gdy poprzednie plany czytają odpowiednio 10% * liczba_rekordów (pierwszy) i 20% * liczba_rekordów (drugi) i oba sortują 10% rekordów całej tabeli. Pewnie DB/2 lub Oracle potrafiłoby znaleźć ten plan bez hintów, ale muszę sprawdzić. Jeśli optymalizator nie zauważy, że można wyeliminować sortowanie oraz że można przerwać skanowanie po osiągnięciu 10 rekordów wyniku, ten plan automatycznie staje się prawie najgorszym z możliwych. To tyle omówienia zadania. Zadanie miało na celu tylko zilustrowanie, że problem wprawdzie prosty nie jest i rozwiązanie mocno zależny od jakości optymalizatora bazy danych, to nie jest wcale żadną tajemnicą, co potrafią robić różne optymalizatory i program może to uwzględniać. Wydaje mi się, że nawet w niektórych przypadkach może to zrobić lepiej niż człowiek - kto z Was zna szczegóły działania optymalizatora MySQL czy PostgreSQL? Raczej stosuje się metodę "prób i błędów" a nie podejście naukowe. Podobnie program bez trudu potrafi oszacować selektywność warunków i zrobić podobną analizę, którą przedstawiłem przy okazji zadania. BTW. Istnieje taki projekt dla DB/2 i działa nieźle. Dla MySQLa byłoby dużo prosciej, bo on potrafi zdecydowanie mniej (ma regułowy optymalizator -> łatwo się go przewiduje). Ponadto nie zalezy mi na tym, by ten program dawał zawsze najlepszy możliwy wynik, ale żeby raczej stanowił pomoc w "zgrubnym" dobraniu większości indeksów, w bardzo krótkim czasie. -------------------- Projekty: PLAY, optymalizator baz danych
|
|
|
Wersja Lo-Fi | Aktualny czas: 27.09.2024 - 05:41 |