publikuj: Opublikuj w wykop.pl Opublikuj we flaker.pl Opublikuj na OSnews.pl Opublikuj w delicious wydrukuj
44 skomentuj »

TAGI: mysql , optymalizacja , php

2011-02-28 08:55  |  Tomasz Smykowski

10 przykładów pokazujących jak nie budować zapytań w MySQL

10 przykładów pokazujących jak nie budować zapytań w MySQL

Pisanie zapytań w MySQL to nie jest programowanie strukturalne. Zupełnie inna filozofia skutkuje innymi sposobami rozwiązywania problemów i powstawaniem sztuczek, których znajomość ułatwia życie programistom i bazodanowcom zmagającym się z rosnącą liczbą krotek. Przedstawiamy 10 przykładów naprawdę złych zapytań MySQL znanych z doświadczenia swojego i potwierdzonych przez innych. Nie próbujcie tego w pracy!

Cześć z przedstawionych przykładów może wydawać się wam oczywista, ale jednak nadal wiele z nich znajdziesz w kodzie, nad którym pracujesz – szczególnie gdy sam go nie pisałeś.

 

1. Odciążę MySQL od liczenia krotek

Wyobraź sobie, że trzeba policzyć liczbę produktów w dużym sklepie handlowym. Programista napisał zapytanie, które ukształtował w następujący sposób:

SELECT * FROM hall_products

Ale zaraz, gdzie podziało się liczenie? A to już jest w PHP:

<? $liczba = count($tablica_wynikow); ?>

Jak widać autor rozdzielił pobieranie danych od ich liczenia. Zawartość wszystkich krotek z tabeli musi zostać przekazana do skryptu PHP, który następnie policzy te dane. MySQL poradzi sobie jednak o wiele lepiej z ich liczeniem, jednocześnie zmniejszając nakład pracy na przesyłanie ich do PHP.

Jeżeli więc nie potrzebujesz wszystkich danych, a tylko ich liczbę, użyj zapytania:

SELECT COUNT(*) FROM hall_products

COUNT(*) sprawdza się w przypadku tabel MyISAM, które cache’ują liczbę wierszy. W przypadku InnoDB – jeżeli nie masz klauzuli WHERE, dobrze będzie ją dodać, albo skorzystać z innej metody, np. zapytania SHOW TABLE STATUS LIKE 'hall_products', które pokazuje w kolumnie Rows przybliżoną liczbę wierszy (dobrą, gdy tabela nie jest nazbyt dynamiczna).

 

2. Będę trzymał pliki w jednej tabeli z resztą danych

Robisz stronę z tekstami piosenek i chcesz je przechowywać w bazie danych. Zdefiniowałeś tabelę i dodałeś do niej kolumnę tekstową TEKST. Tekst będzie dłuższy niż kilka kilobajtów. Żaden problem? A jednak.

Jeżeli umieścimy taką kolumnę, wraz ze wzrostem liczby krotek z tekstami zapytania będą wykonywać się coraz wolniej, nawet jeżeli masz odpowiednie indeksy. Jest to związane nie tylko ze znanym błędem w MySQL, ale i sortowaniami tych danych, które muszą być wykonywane na dysku.

Aby ustrzec się takich problemów, większe pola różnej długości oddziel od głównej tabeli do nowej, łącząc je powiązaniem 1:1. Przykład poniżej.

CREATE TABLE teksty (
 id int UNSIGNED NOT NULL AUTO_INCREMENT,
 autor varchar(255),
 PRIMARY KEY(id)
);
 
CREATE TABLE teksty_dane (
 teksty_id int UNSIGNED NOT NULL.
 tekst_piosenki text ,
 PRIMARY KEY(teksty_id) );

«poprzednia 1 2 3 4 ... 5 następna »

publikuj: Opublikuj w wykop.pl Opublikuj we flaker.pl Opublikuj na OSnews.pl Opublikuj w delicious wydrukuj
44 skomentuj »

Warto przeczytać

Potrzebujesz własnej chmury na pliki? Wypróbuj ownCloud 4, teraz z wersjonowaniem i podglądem ODF
Jak w prosty sposób zmierzyć czas wykonywania skryptu PHP?
Uwaga na groźną luką w PHP; na celowniku serwery pracujące w trybie CGI
Nie przegap, czyli TOP5 najchętniej czytanych tekstów minionego tygodnia

Komentarze

  • awattar
  • dAREuS

    #2 dAREuS® 2011-02-28 09:55:19 1

    Dla osób, które uważają, że w MySQL nie ma COUNT() - http://dev.mysql.com/doc/refman/5.1/en/counting-rows.html

    IP: 188.121.11.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13

  • Jacek_S

    #3 Jacek Smolak® 2011-02-28 10:25:16 0

    No i lepiej COUNT(1) zamiast COUNT(*)

    IP: 81.161.201.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

  • Kiki
  • xxx
  • dAREuS

    #6 dAREuS® 2011-02-28 10:46:36 0

    Usuwamy komentarze, które po prostu nadają się tylko do usunięcia.

    IP: 188.121.11.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13

  • SIR JEDI

    #7 SIR JEDI 2011-02-28 10:52:48 1

    count(*) działa tylko dla myisam i tylko dla zwracania ilości wierszy w całej tabeli (bo to jest przchowywane przez storage engine). Dla innodb jest to nieefektywne.

    count(1) jest głupotą - storage engine nie wie wtedy, czy chcesz zliczyć wszystkie wiersze w tabeli.

    A jak już piszecie o łączeniu tabel, to sugeruje uczyć joinów a nie łączenia kartezjańskiego 2 zbiorów danych i wykonywania kosztownej operacji grupowania na tabeli tymczasowej, która powstała z waszej operacji i jest ogromnych rozmiarów....

    IP: 193.25.1.[...] Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13

  • tomaszs

    #8 tomaszs® 2011-02-28 12:18:28 0

    @xxx

    Zastanawiam sie co zawieral pierwotnie Twój komentarz skoro teraz piszesz o autorze, że jest pseudoprogramistą.

    Jak już uważasz, że są lepsze i wydajniejsze rozwiązania to zapewne wszyscy tutaj chcieliby o nich usłyszeć i każdy doceni jeżeli wniesiesz coś do dyskusji.

    IP: 89.74.21.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

  • Zaksmok

    #9 Zaksmok 2011-02-28 12:39:00 1

    Poprawny kod powinien wyglądać tak:

    $wszystkie_dane = pobierzProdukty(count($wiersze)); //pobranie danych dla i od 0 do count($wiersze)

    $count = count($wiersze);

    for ($i=0; $i

    IP: 195.82.171.[...] Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.20 (KHTML, like Gecko) Chrome/11.0.672.2 Safari/534.20

  • veritas

    #10 veritas 2011-02-28 13:02:01 0

    Wydaje mi się ze w 10 powinna być mała poprawka:

    Indeksy mogą zostać wykorzystane pod warunkiem ze wartość jest stałą lub nie zaczyna się od %.

    http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

    # B-Tree Index Characteristics

    IP: 95.49.86.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

  • slawek22

    #11 slawek22 2011-02-28 13:57:41 0

    @xxx - FOUND_ROWS nie jest szybsze niż select count. Piszą to chyba ludzie którym coś tam świta po przeczytaniu dokumentacji ale nie znają zbyt dobrze angielskiego.

    Działa to tak samo szybko (albo wolno) jak count. Serwer po prostu zwraca liczbę wierszy tabeli i tego nie da się zrobić inaczej obojętnie czy sobie używasz jednego słowa kluczowego czy drugiego.

    Pewnie nikogo nie przekonałem bo takie bzdury trafiają na bardzo podatny grunt. Już w szkole uczą, że im rozwiązanie jest trudniejsze i bardziej debilne tym lepiej.

    http://www.phpdevblog.net/2009/06/mysql-pagination-sql-calc-found-rows-vs-count-query.html

    Jedyne co to robi... to popsucie cache'u dla kwerend. W normalnych warunkach (nawet jak tabela często się zmienia) - nigdy nie powinno się tego używać. Bo za każdym razem mySQL musi przetworzyć cały result-set a nie może cache'ować kwerendy. Nawet jak sam to zrobisz w oddzielnym cache i dla niektórych kwerend wyrzucisz CALC a pobierzesz wartość z QC... to skończy się tym że QC będzie zajmowało 2x tyle miejsca ile powinno a kwerendy będą wykonywały się wolniej (chyba nie muszę tłumaczyć dlaczego).

    Let's assume we're on a high-traffic website where performance matters, so we turn the query cache on. MySQL Query caching is like a key-value cache with the key being the EXACT

    Once we turn on the cache, the pagination is way faster with the query using COUNT(). Why? When using SQL_CALC_FOUND_ROWS the application has to calculate the found rows every single time we turn the page, because the query changes. While the COUNT()-Query always remains the same, meaning that its result comes from the query cache from the second time on.

    Co do przykładów z "JOIN" - zdejmijcie to, na prawdę. Jak takie coś pokażecie pierwszemu lepszemu dzieciakowi to was wyśmieje. Akurat te przykłady "jak budować" to najlepszy przykład jak nie budować. Więc to będzie moja sugestia. Jak sobie z tym poradzić pewnie piszą w każdej książce do jakiegokolwiek SQL-a, gdzieś ok. 10 strony.

    IP: 83.4.109.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13

  • xxx

    #12 xxx 2011-02-28 14:03:18 0

    @Slawek22

    FOUND_ROWS nie trzeba wykorzystywać z SQL_CALC_FOUND_ROWS.

    IP: 46.113.200.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13

  • slawek22

    #13 slawek22 2011-02-28 14:14:55 0

    Pozostaje pytanie o sens takiej konstrukcji. To znaczy zwykle i tak nie potrzebujesz informacji o tym ile wierszy zwróciła ostatnia kwerenda. A jeśli już potrzebujesz to zrobienie prostego count w php na zbiorze danych który przetwarzasz jest dużo szybsze niż ponowne odpytanie serwera.

    FOUND_ROWS bez CALC nie ma najmniejszego sensu.

    Dajmy na to wyświetlasz 10 postów na forum. Używasz foreach. Jak lubisz

    "pradawne" konstrukcje to pętli for. Ale nigdy nie będziesz odpytywał serwera ... ile wierszy ma tablica którą właśnie dostałeś z jakiejś warstwy pośredniej bo to byłby po prostu idiotyzm. W idealnych warunkach będzie to 2x wolniejsze (2 cache hits zamiast jednego).

    IP: 83.4.109.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13

  • xxx
  • xxx
  • Kiki
  • dAREuS

    #17 dAREuS® 2011-02-28 14:41:46 0

    xxx, jak widać daje, bo napisałeś pierwszy komentarz, który nie jest obraźliwy. Poza tym - nie wiem, czy jesteś tego świadomy - w powyższej dyskusji są również twoje nieusunięte komentarze, które również nie uznaliśmy za obraźliwe. To tak wychowawczo.

    A pierwszy został usunięty, ponieważ napisałeś w nim, że w MySQL nie ma COUNT () i kilka jeszcze rzeczy, które nikogo myślę, nie obchodzą. Jeśli chcesz tutaj rozmawiać o MySQL, zapraszamy.

    IP: 188.121.11.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13

  • xxx
  • PentagonX
  • dAREuS

    #20 dAREuS® 2011-02-28 15:48:21 1

    PentagonX, to że raz na setkę komentujących trafi się xxx, nie oznacza, że mam innym użytkownikom wyłączać możliwość komentowania. To by oznaczało, że się daliśmy sterroryzować.

    Po drugie, usuwamy jakiś niewielki promil komentarzy, które naprawdę nadają się do usunięcia, co już napisałem powyżej.

    IP: 188.121.11.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13

  • kici

    #21 kici 2011-02-28 20:14:38 0

    "Cześć z przedstawionych..." heh a no "cześć" ;) ... hm, a może "Część"?

    IP: 81.190.124.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

  • Fan_Smykowskiego
  • tomaszs

    #23 tomaszs® 2011-03-03 13:40:35 0

    @Jacek S.

    Pewnie, jak wolisz pisać COUNT(1) to

    czemu nie. Z punktu widzenia

    wydajności oba zapytania COUNT(1) i

    COUNT(*) działają tak samo szybko i

    dają takie same wyniki :)

    @Kiki

    Jeżeli odnosisz się do pkt. 9 to

    ten punkt mówi o niezagnieżdżaniu

    zapytań, a Ty piszesz o kolejnym krok

    optymalizacji który oczywiście też

    jest ważny.

    @SIR JEDI

    Patrz odp. do @Jacek S.

    Oczywiscie można napisać to zapytanie jeszcze lepiej, a później jeszcze i jeszcze. Wszystko zależy od struktury bazy i relacji.

    @Zaksmok

    Dzięki to jest oczywiście kolejna

    optymalizacja którą można zaaplikować

    chociaż dotyczy bardziej samego PHP a

    nie MySQL :)

    @veritas

    Nie bardzo wiem o co chodzi... to co napisałeś to prawda i to samo

    jest napisane w punkcie 10, albo się mylę?

    @slawek22

    No nie zawsze jak widać warto przekombinowywać.

    Co do JOIN -> patrz odp. do @Jacek S. i @SIR JEDI. To tak jak z nauką jazdy jednośladem. Jak ktoś nie umie jeszcze jechać rowerem to nie wsadzisz go od razu na żużlowy motor. Najpierw rower potem motor tak bezpieczniej i lepiej zrozumie zasadę równowagi na rowerze.

    Traktujcie przykłady w tekście jako pomagające zrozumieć na czym polega pierwotny błąd w danym zapytaniu a nie jako najbardziej optymalne rozwiązanie na świecie. Co z tego że bym dał tam wersję którą mam w swoim kodzie jakby czytająca to osoba w ogóle nie zrozumiała na postawie tego gdzie popełnia błąd i jak zrobić pierwszy krok w kierunku naprawy?

    Coś co dla Ciebie może być oczywiste dla kogoś innego kto jeszcze nie ma takiego doświadczenia jak Ty może już nie być. Warto sobie przypomnieć jak to było kiedyś jak się zaczynało. A myślę, że akurat w tym artykule każdy znajdzie coś dla siebie - i początkujący i ktoś kto jest już profesjonalistą bo nawet wtedy może odświeżyć sobie informacje które już zna.

    @PentagonX

    Podejrzewam, ze raczej xxx miał skasowane posty za kolejne epitety, chociaż akurat pokemon o którym myślę teraz to według mnie bardzo sympatyczne zwierzątko :)

    Nową inkarnacją xxx jest zapewne @Fan_Smykowskiego.

    xxx aka @Fan_Smykowskiego

    Przestać robić histerię wokół własnej osoby. Jakoś wszyscy tutaj normalnie się wypowiadają nawet jak mają odmienne zdanie ode mnie czy innych tylko Ty jakoś nie potrafisz się dostosować. Szanowni czytelnicy powyżej bardzo trafnie uzupełnili artykuł i nie kłam, że artykuł był zmieniany bo nie był.

    A teraz merytorycznie: Nie ma COUNT? - pozostawię to bez komentarza.

    Pozdrowienia dla wszystkich komentujących, pamiętajcie dzisiaj tłusty czwartek i można zajadać się pączkami do woli :)

    IP: 89.74.21.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

  • Fan_Smykowskiego
  • tomaszs

    #25 tomaszs® 2011-03-03 16:17:23 0

    @Fan_Smykowskiego

    "Tak się składa, że pisanie o Count(1) tak samo jak o Count(*) to tak jakby powiedzieć, że 1 kolumna = całej tabeli"

    1 to nie kolumna a wartość skalarna także to porównanie jest nieprawdziwe. I to nie prawda, ze daje inne wyniki bo daje takie same. ale głupoty. A ten nick to po co? żeby pisać merytorycznie? wątpię.

    IP: 89.74.21.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

  • slawek22
  • tomaszs

    #27 tomaszs® 2011-03-03 20:20:42 0

    @slawek22

    Sam kiedyś byłem niedawno czytelnikiem więc wiem jak to jest i naprawdę cenię sobie to ilu tu jest doświadczonych programistów i w szczególności tych, którzy dodają swój wkład w komentarzach dla innych.

    Także jak już rozmawiamy o tym to czy mógłbyś zaproponować Twój wariant tego zapytania? To już będzie już uzupełnienie tej dyskusji i każdy czytelnik będzie mógł poza naprawą błędu właściwego jeszcze ulepszyć swoje zapytanie.

    IP: 89.74.21.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

  • huxley

    #28 Aldous Huxley® 2011-03-03 20:57:03 1

    Wkradła się chyba drobna nieścisłość, proszę mnie poprawić jeśli się mylę.

    "Przy okazji dobrze jest zwrócić uwagę, że nierówności w BETWEEN są nieostre, a więc nie należy używać zapytania zawierającego BETWEEN '2011-01-01' AND '2011-12-31', które zgubi wiersze z ostatniego dnia roku."

    Nierówność ostra to &gt; lub &lt; Moja ulubiona pani od topologii zwykła mawiać, że trzeba naostrzyć nierówność. Nie wiem jak działa BETWEEN, jeśli jednak "gubi" ostatni dzień roku w ww. przykładzie, to domyślam się, że nierówność jest ostra.

    Czy chodzi o przedział lewostronnie domknięty ['2011-01-01', '2011-12-31')?

    IP: 88.156.38.[...] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

  • slawek22
  • tomaszs

    #30 tomaszs® 2011-03-04 09:22:59 0

    @slawek22

    Nie trzeba pisać INNER JOIN, wystarczy JOIN

    Wydajność INNER JOIN w tym przykładzie jest identyczna jak SELECT FROM WHERE

    Plan wykonania jest taki sam jak zapytania w artykule

    Przykładowe wyniki:

    WHERE:

    0.1245

    0.1618

    0.0007

    0.0009

    0.1391

    INNER JOIN:

    0.1102

    0.1355

    0.0007

    0.0008

    0.1368

    Pisałeś, że to zapytanie jest "źle zrobione". W jakim sensie? Zwraca dobre wyniki, ma taką samą wydajność jak Twoje zapytanie. To gdzie to złe zrobienie?

    Także jedyne co może przemawiać w tym przykładzie za użyciem słowa kluczowego JOIN to kwestia przejrzystości kodu, która zresztą w tym przykładzie też nie ma zbytnio racji bytu bo ten kod sam się wyjaśnia. W większych zapytaniach owszem ale na pewno nie tu.

    Ale oczywiście jak powstanie drugi odcinek artykułu to skupiony bardziej na estetyce kodu a nie wydajności to zapewne będzie to dobry przykład z tymi JOIN-ami :)

    IP: 89.74.21.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10

  • web4u.pl

    #31 web4u.pl 2011-03-06 15:55:49 1

    witam, zawsze warto przypomnieć sobie podstawy. Ciekawy artykuł - polecam.

    IP: 83.11.121.[...] Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13

  • pAq
  • slawek22

    #33 slawek22 2011-03-07 19:57:21 0

    @Tomasz... nie tylko. Pierwszy (twój) sposób to implicit join, Microsoft już to porzuca.

    Drugi sposób (mój) to explicit join. Wydajnościowo to jest może to samo ale się implicit nie używa właśnie ze względu na nieczytelność.

    http://msdn.microsoft.com/en-us/library/dd172122.aspx

    IP: 83.22.179.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13

  • tomaszs

    #34 tomaszs® 2011-03-08 00:15:59 0

    @pAq

    Pierwszy akapit sie zgadza. Drugi - nie. Jak trzymasz daty w datetime to pierwszy dzien 2012 nie zostaje uwzgledniony.

    IP: 89.74.21.[...] Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

  • tomaszs

    #35 tomaszs® 2011-03-08 00:17:35 0

    @slawek22

    To jest link odnosnie T-SQL a nie MySQL i nie sadze, zeby moc uznawac to za jakas wyrocznie. Poza tym w tym przykladzie nie sadze, zeby czytelnosc cierpiala na tym. No ale to juz sa takie dyskusje czysto akademickie.

    IP: 89.74.21.[...] Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

  • pAq

    #36 pAq 2011-03-08 14:45:58 1

    @tomaszs

    Ok, jesli mowa o DateTime to rzeczywiscie nie zostanie uwzgledniony CALY pierwszy dzien 2012 roku.

    Jednak nie zmienia to faktu, ze przy takim typie kolumny dalej w zapytaniu jest blad, poniewaz uwzgledni ono wiersze, ktorych Artykuly.publikacja = '2012-01-01 00:00:00'. Czyli zwroci tez artykuly, ktore byly opublikowane w pierwszej sekundzie 2012 roku :)

    Wiem, ze w praktyce ciezko zeby takie cos mialo miejsce ale jednak jest to blad ;)

    IP: 193.25.4.[...] Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15

  • 3tretrt63wtrwqet54
  • tomaszs

    #38 tomaszs® 2011-03-11 13:25:58 0

    @pAq

    Czyli np. wyświetlając wpisy na blogu z 2010 roku zobaczysz wpis opublikowany o godzinie 00:00 1 dnia 2011 roku. Ale kiedy wybierzesz wpisy 2011 roku to normalnie zobaczysz ten wpis z godziny 00:00. Więc jakby w praktyce ten błąd nie ma znaczenia, ale masz rację że teoretycznie to bardzo dobra ciekawostka. Byłem ciekaw kiedy ktoś to zauważy :) brawo!

    IP: 89.74.21.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 ( .NET CLR 3.5.30729; .NET4.0C)

  • Pluto

    #39 Pluto 2011-03-24 17:00:23 0

    Mała uwaga do kodu PHP w pkt. 9

    Bardzo częsty błąd popełniany w pętlach for:

    for ($i=0; $i

    IP: 89.171.104.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24

  • Pluto

    #40 Pluto 2011-03-24 17:02:07 0

    Obcina komentarze przy znaku mniejszości jak by cięło htmla :|

    IP: 89.171.104.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24

  • leszlo

    #41 leszlo 2011-03-24 18:16:08 0

    pkt. 5. też nie jest do końca prawdą.

    Istnieją przypadki gdzie bardziej zagnieżdżanie zapytań opłaca się bardziej niż łączenie dwóch bardzo dużych tabel. Ale mówimy o tabelach powyżej 500 tys. rekordów. Miałem okazję się o tym przekonać i przyspieszenie było rzędu kilkuset procent.

    Tak że dobrą praktyką dla początkujących będzie sprawdzenie obydwu wariantów.

    IP: 83.6.148.[...] Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0

  • tomaszs

    #42 tomaszs® 2011-03-24 18:17:26 0

    @leszlo

    Czy byś mógł podać konkretny przypadek?

    IP: 89.74.21.[...] Mozilla/5.0 (Windows NT 6.0; rv:2.0) Gecko/20100101 Firefox/4.0

  • Mik

    #43 Mik 2011-04-01 13:41:39 0

    punkt 7 - zły zakres dat, żeby pobrało 2011-01-01 (analogiczny powód do 2012-01-01).

    IP: 95.50.83.[...] Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16

  • Michal K.

    #44 Michal K. 2011-05-22 22:47:09 0

    http://www.phpbench.com/

    IP: 78.149.254.[...] Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Odśwież

Uwaga! Możesz zarejestrować się w serwisie i w ten sposób zarezerwować swój nick oraz ominąć konieczność ciągłego odczytywania wyrazów.

Aby dodać komentarz, musisz podać swój nick, treść komentarza oraz poprawnie przepisać oba słowa z obrazka (słowa muszą być rozdzielone spacją).
W treści komentarza można używać języka formatowania BBcode.

Popularne 7 dni 30 dni

Społeczność komentarze forum

Polecane książki

Praca

Czytaj Webhosting

Chcesz być na bieżąco z naszymi informacjami? Zapisz się na Newsletter.

Zarejestruj domenę

Sprawdź dostępność swojej domeny:

.pl: 0 zł   .com: 19.90 zł
.com.pl: 0 zł   .eu: 19.90 zł