![]() |
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.
![]() |
![]()
Post
#1
|
|
Grupa: Moderatorzy Postów: 36 559 Pomógł: 6315 Dołączył: 27.12.2004 ![]() |
Zgodnie z życzeniem: "Profilowanie aplikacji".
Zachęcam do udziału w dyskusji (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) |
|
|
![]() |
![]()
Post
#2
|
|
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ć (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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 |
|
|
![]()
Post
#3
|
|
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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) 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ć. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 15.10.2025 - 03:11 |