Názory k článku PHP okénko: Získání počtu řádek
-
"Druhý způsob je naproti tomu velice rychlý, protože MySQL jenom vezme počet řádků tabulky, který si vede jako statistický údaj, a vrátí ho."
Brutálně MySQL-specifická optimalizace. Jinde nepoužitelná.
Totéž druhá polovice článku. Nemělo by se to jmenovat spíš MySQL okénko???
Mimochodem, jak je ten "statistický údaj" imunní vůči transakčnímu zpracování? -
No mozna, ze MySQL to ma optimalizovano lepe nez tvoje oblibena databaze (protoze MySQL je optimalizovane kvalitne), ale bez ohledu na databazi bude druha moznost rychlejsi. PHP totiz implicitne pri mysql_query (narozdil od mysql_unbuffered_query) poctive precte celou odpoved SQL serveru a obavam se, ze stejne se chovaji i ostatni databazova rozhranni.
BTW, SQL server muze byt umisten i na jinem stroji nez apache - takze tahani vysledku muze zatizit i sit. -
anonymníNikdy jsem netvrdil, že bude rychlejší první možnost! Nebude, zcela samozřejmě. Ale tvrzení, že „to bude rychle, protože MySQL si to ukládá bokem průběžně“ je jednak MySQL-specific (což v „PHP okénku“ zamrzí), jednak stále ještě netuším, jak je to s concurrency a transakcemi. Jakmile mám snapshot transakce, můžu mít tolik různých počtů řádek, kolik mám transakcí, že...
Tohle absolutně nemá co dělat s optimalizací databáze, spíš s jejím „přihýbáním“ některým typizovaným použitím. Zde hrozí riziko, že budu uvažovat jinak než autoři a „optimalizace“ mne naopak postihne v podobě zfušované jiné části kódu, které se autoři tolik nevěnovali. Toho se mírně obávám... -
Ano, s tim pochopitelne souhlasim - vysvetleni, ktere jsem uvedl ja (nebo lepsi :-)) melo byt jiz v clanku. Jeste klika, ze tu jsou diskuse, ve kterych je mozne clanek doplnit ...
Take netusim, jak presne to funguje s transakcemi, nicmene nemyslim ze by v tom byl nejaky problem - pocet radek, ktery dostanete, nemusi byt za chvilku spravny ani bez transakci, stejne je nutne brat ho jen jako odhad (pokud tedy nemate tabulku zamcenou).
V pripade Javy se tomu rika "hotspot optimalizace". Ve skutecnosti se ale tento prvek vyskytuje prakticky v kazde optimalizaci - snazite se dosahnout nejlepsiho vykonu pro nejcastejsi pouziti a nutne tim snizujete vykon jindy. Dokonce i algoritmy pro loseless kompresi dat lze popsat podobne. A prekvapko - vetsinou to funguje. -
S transakcemi problém je, protože count(*) nemá co být odhadem, ale počtem řádků viditelných pro transakci. „pocet radek, ktery dostanete, nemusi byt za chvilku spravny ani bez transakci“ - tak tomu už neriozumím vůbec...
Vidím v poznámce ohledně zamykání tabulek náznak, že uvažujete poněkud omezeně – neberte to prosím jako urážku – já například ještě neměl tu čest pracovat s databází, která by tabulky musela zamykat (a i když to mnou používané servery na požádání dokáží, opravdu jsem to nikdy nepotřeboval), takže nemám _co_ zamykat :)
Hotspot? Dobře, ale hotspot optimalizuje metody, které používám a ostatní nechá být. Když budu MySQL používat určitým způsobem, předesignuje se sama tak, aby byla pro mou aplikaci rychlejší? :))) -
Copak podpora češtiny, ta ještě jde, ale co teprve logické myšlení čtenářů, kteří si myslí, že výkřik v názorech je spolehlivější než e-mail o problému na adresu provozovatele.
Díky za podnět, předal jsem kolegům. Mimochodem, zkuste si uvozovky či dlouhou pomlčku při zadání názoru s formátováním XHTML - je to lepší? -
Michal Kubeček (neregistrovaný)
já například ještě neměl tu čest pracovat s databází, která by tabulky musela zamykat
Já dokonce nejčastěji pracuji s databází, která když nedávno (po dvaceti letech své existence) explicitní zamykání tabulek umožnila, považovali vývojáři za nutné vysvětlit v release notes uživatelům, k čemu by to vlastně mohlo být dobré…
-
Krucifix ... nepsat reakce tesne pred spanim ...
Jak napsal Michal Kubeček, zalezi na nastaveni úrovne izolace transakci. Podrobnejsi vysvetleni radsi necham na nem, protoze jak jste spravne odhadl moje zkusenosti s transakcemi jsou omezene, presneji omezene jen na teoreticke znalosti. V praxi je pro me mnohem pochopitelnejsi princip zamykani tabulek a atomickych operaci. Mimochodem, ve vetsine webovych aplikaci se skutecne muzete obejit bez explicitniho zamknuti tabulek, protoze si vystacite s atomickymi operacemi (a pomuckami typu last_insert_id).
Ano, hotspot je optimalizace velmi dynamicka. Presneji receno, Java byla optimalizovana tak, ze se vzdala rychlejsi metody optimalizace natvrdo ve prospech adaptibilnejsi metody schopne optimalizovat primo pri behu. Asi to nebyl nejvhodnejsi priklad, nicmene na principu to nic nemeni - "přihýbání některým typizovaným použitím" je pomerne presne vysvetleni pojmu optimalizace, nikoliv jeho protiklad.
A sice by se mi taky libilo, kdyby nektere optimalizace byly dynamictejsi, ale v pripade ukladani poctu radek (ktere navic MySQL muze potrebovat pro interni ucely, napriklad pro odhad optimalnejsiho smeru joinovani tabulek) by jakykoliv pokus o dynamizaci skoncil narocnejsi. -
Satano (neregistrovaný)Podľa mňa COUNT(*) nie je nikdy odhadom, ale práve počtom riadkov viditeľných pre transakciu. A koľko riadkov transakcia vidí, záleží na jej úrovni izolácie (môžete, ale aj nemusíte vidieť nové riadky od iných transakcií). Akurát, že ten vrátený počet riadkov je presný práve iba v dobe (lepšie je asi v stave DB), kedy to tá transakcia ráta. S tým súvisí aj to, že vrátený počet riadkov nemusí byť správny ani bez transakcie. COUNT(*) si to všetko zráta, ale kým sa to spracuje (napr. PHPčkom) a odošle naspäť k vám (narp. vo forme www stránky), moholi byť do DB vložené ďalšie riadky, alebo niektoré vymazané, takže to číslo, čo vidíte v skutočnosti správne nie je. Ale nie je to ani odhad. Proste bolo správne v čase a stave, keď ho DB rátala.
Trošku off-topic, ale k tomu zamykaniu tabuliek. Tiež som veľmi dlhú dobu nemusel tabuľky v DB zamykať. Nebol nejaký vážny dôvod pre to a okrem toho asi všetky projekty bez ohľadu na to, ako intenzívne využívali DB, ju využívali hlavne na čítanie a ak na zápis, tak tie zápisy sa medzi sebou 'nebili' (napr. užívatelia portálu si väčšinou modifikujú každý svoje dáta a pod.). Avšak pri poslednom projekte došlo aj na zamykanie tabuliek. Ako DB server je použitý PostgreSQL (a transakčné spracovanie samozrejme - kôli tomu bol vybraný namiesto MySQL). Ale problém bol, že užívatelia systému sa snažia pristupovať a meniť rovnaké dáta a bez zamykania tabuliek mi tam vznikali deadlocky. Tie zmizli, keď som začal tabuľky zamykať a okrem toho to malo pozitívny vplyv aj na výkon - citeľne klesol load na servri (asi vďaka odstráneniiu deadlockov). -
Satano (neregistrovaný)Transakcie robia zmeny, v 2-4 tabuľkách, pričom zmeny sa môžu týkať viacerých riadkov naraz a je určitá podmnožiona riadkov, ktoré sa snažia meniť viaceré transakcie súčasne. V manuáli PostgreSQL je popísaný jedna možnosť, kedy môže dôjsť k deadlocku a aj jeho odstránenie. To spočíva v tom, že všetky zmeny, ktoré transakcie v tabuľkách robia, musia byť vykonávané v rovnakom poradí. Toto sa mi však nepodarilo dosiahnúť a tak som skúsil to explicitné zamykanie tabuliek, ktoré pomohlo.
Nepovažujem sa za špecialistu databáz, ale ani za nejakého amatéra. Zase si ani nemyslím, že tento model je zle navrhnutý. Vždy je čo vylepšovať, dokonca aj v tomto prípade viem, čo by sa ešte dalo vylepšiť, aj keď v tejto fáze to už možné nie je. Ale to by neodstránilo ten problém, ktorý tam vznikal (podľa mňa). -
> bez zamykania tabuliek mi tam vznikali deadlocky.
Myslim si, ze ide o chybu v navrhu aplikacie ( dlhe zotrvavanie v tranzakcii, update velkeho mnozstva riadkov ).
Ja by som skor ocakaval, ze k deadlockom bude dochadzat pri zamykani celych tabuliek ( zmeny do viacerych tabuliek v jednej tranzakcii ).
BTW. Jediny ( mne znamy ) dovod preco zamykat cele tabulky je aby sa odhlahcilo DB-serveru pri masivnom update/delete velkeho poctu riadkov. Pri takychto operaciach by musel DB-server vytvorit vela zamkov, pricom zamknutim celej tabulky tuto reziu nepotrebuje. Toto je specialny pripad, iny dovod ma nemapada. Vie niekto o inom dovode, preco je potrebne zamykanie tabuliek ? -
Druhy duvod proc zamykat cele tabulky: kdyz je databazocy server napsany spatne :-).
Pri zamykani tabulek nemuze dojit k deadlocku, protoze SQL implementuje metodu predchazeni deadlocku metodou napadnuti podminky drz a cekej. Proces, ktery drzi zamcene tabulky, nemuze zamknout zadne dalsi.
Pochopitelne, nelze vyloucit deadlock pres interni zamky db serveru, ale to uz by znamenalo ze je v nem bug. -
Program 1.)
begin work;
lock table A;
lock table B;
...
Program 2.)
begin work;
lock table B;
lock table A;
...
Je len na slusnosti programatora, ci urobi vsetky zamknutia hned na zaciatku tranzakcie ( velmi casto nie :-( ). Tiez sa moze stat, ze zbytocne zamknem tabulku, ktoru som ( v niektorej vetve algoritmu ) zamykat nemusel.
Navyse zamknutim tabulky zakazem pocas trvania tranzakcie spracovanie vsetkych selectov, a teda znizim priepustnost aplikacie ako celku. -
Tak vy sice tvrdíte, že to je "Brutálně MySQL-specifická optimalizace. Jinde nepoužitelná.", ale v zápětí dodáváte: "Nikdy jsem netvrdil, že bude rychlejší první možnost!".
SELECT COUNT(*) je obecně rychlejší než SELECT * a důvod, proč tomu tak je, je v článku popsán. V některých databázích (tuším ve starších Oracle) může být ještě rychlejší SELECT COUNT(id), ale na principu věci to nic nemění.
Nechci rozebírat, jak to funguje spolu s transakcemi v jednotlivých databázích, ale obecně se dá myslím říci, že to bude v souladu se selským rozumem - INSERT nebo DELETE dosud neviditelný pro venek transakce změní čítač počtu řádek pouze v rámci transakce. -
Satano (neregistrovaný)IMO ten štatistický údaj je voči transakciám imúnny úplne. Pretože MySQL transakcie nepodporuje na natívnych tabuľkách (MyISAM), ale na iných (InnoDB) a tam sa už počet riadkov (pokiaľ moje informácie siahajú) neuchováva ako štatistický údaj, ale počíta sa, ako pri iných databázach.
-
Clanok sa zaobera praktickou realizaciou problemu "Zistit pocet riadkov vracanych selectom". Polozme vsak otazku : "Je to potrebne ?"
Nemam namietky voci "select count(*)" ak je potrebne zistit iba pocet riadkov a nepotrebujem zistovat data. Je vsak velmi neefektivne ak po "select count(*)" nasleduje "select *" s rovnakou where podmienkou. Okrem v diskusii uz spominanom probleme s tranzakciami/zamykanim, je tu aj vykonovy problem ( priepustnost ).
Na zistenie poctu riadkov musi databazovy server (je jedno aky DB server) vyhodnotit kompletnu mnozinu riadkov, to jest pristupit na vsetky riadky, ktore vyhovuju where podmienke ( pri vhodnom nastaveni indexov, pristupuje iba k indexom, nie k datovym strankam ). Ak nasleduje "select *" musi cely postup zopakovat este raz, ale teraz uz (zvycajne) musi pristupovat aj k datovym strankam. Navyse ak chcem mat zhodujuci sa vysledok zo "select count(*)" a "select *", tak musim obe operacie urobit v tranzakcii s REPEATABLE-READ.
Samozrejme je tu moznost spocitat riadky na strane web/app-servera. To ale znamena nacitat vsetky vysledne riadky zo "select *" do pamati web/app-servera, takze pozor na potencionalne velke mnoziny riadkov. Sem samozrejme patri aj zataz/priepustnost siete medzi web/app-serverom a db-serverom.
Skusme sa vsak zamysliet naco je potrebne zistit pocet zaznamov, ktore vracia select ? Zvycajne sa to zobrazuje na spodu stranky, aby uzivatel vedel ci ma este nejake dalsie nezobrazene riadky. Z praxe viem, ze pouzivatel zvycajne pracuje s najviac prvou, druhou, maximalne tretou obrazovkou, dalej sa mu zvycajne klikat nechce, je mu jednoduchsie obmedzit vracane riadky cez filter.
Uzivatel vsak potrebuje vediet ci ma este dalsie riadky, alebo je uz na poslednej obrazovke. Na zobrazenie tejto informacie vsak nepotrebujem zistovat pocet riadkov zo selectu. Ak sa na obrazovku zobrazuje 100 riadkov, tak nacitam z DB 101 riadkov, ak 101 riadok existuje, zobrazi sa tlacitko "Next page".
Na vybratie iba pociatocnej vzorky zaznamov je mozne pouzit vhodne obmedzenie DB servera ( napr Informix : "select first 101 *", PostgreSQL "select ... limit 101" ). Ak ma DB-server urobenu dobre optimalizaciu, nemusi vyhodnocovat celu mnozinu riadkov, staci ak vyhodnotil potrebny pocet riadkov.
Pri tejto implementacii ma uzivatel dostatok informacii pre svoju pracu, na databazovy server ide iba jeden select a aj ten nemusi DB-server vyhodnocovat uplne do konca.
Uff, je toho viac ako som myslel, takze iba zaver : Skor ako sa pustite do kodovania, urobte si navrh v ktorom zoberiete do uvahy spravanie databazoveho servera. -
"Je vsak velmi neefektivne ak po "select count(*)" nasleduje "select *" s rovnakou where podmienkou."
Škoda, že jste si z článku důkladně přečetl jen první odstavec. Hned ve druhém odstavci je totiž uvedeno "Funkci mysql_num_rows je vhodné použít pouze v případě, kdy data z tabulky budeme tak jako tak potřebovat" i s názorným příkladem a způsobům vyhnutí se tomuto kódu je v podstatě věnován celý zbytek článku.
Co se druhé poloviny vašeho příspěvku týče, je to dobrý postřeh a v článku by to mohlo být zmíněno. "Zvažte, zda celkový počet řádků vůbec potřebujete." -
> Škoda, že jste si z článku důkladně přečetl jen první odstavec
Preletel som to az do konca ( PHP ani mySQL nepouzivam ), takze viem ze to tam bolo uvedene, chcel som to iba zdoraznit.
> v článku by to mohlo být zmíněno
Moj prispevok smeroval k tomu, ze je velmi vela clankov, ktore sa snazia riesit dosledky nejakeho problemu, casto je vsak jednoduchsie odstranit pricinu.
Uzivatelia/analytici odchovani na FoxPro/DBase su zvyknuti na velky komfort, ktory poskytuje toto prostredie ( pocet riadkov / rychle hladanie ), a ocakavaju rovnake spravanie aj pri SQL-serveri. Programator sa zvycajne bez slova podriadi, potom riesi dosledky .... a pocuva poznamky o tom ako je to pomale ... -
Jan Mensik (neregistrovaný)Zajimavy postreh. Opravdu nekdy staci jen zobrazovat "Next Page" a nenacitat celkovy pocet nalezenych radku, ale musim Vam oponovat - vetsinou je celkovy pocet dulezity udaj.
Mate pravdu v tom ze navstevnici klikaji na prvnich par stranek. Ale celkovy pocet vysledku je pro ne zajimavy udaj. Rika jestli jak presne byl jejich dotaz cileny a dle toho casto svuj pozadavek upravi. -
> Ale celkovy pocet vysledku je pro ne zajimavy udaj.
Ano suhlasim, obcas je to zaujimavy udaj.
Preco ho vsak zobrazovat na kazdej stranke ? Tento udaj sa zobrazi az ked si uzivatel vyziada dany udaj.
> Rika jestli jak presne byl jejich dotaz cileny a dle toho casto svuj pozadavek upravi.
Otazka je ci skutocne potrebuje zobrazit pocet zaznamov, alebo potrebuje informaciu "je toho vela". Podla mna je mozne realizovat to napr. takto
* na obrazovke sa zobrazuje 20 riadkov
* pri selecte nacitam 10 obrazoviek ( 20 * 10 + 1 riadok )
* ak bude select obsahovat aj 201 riadok, potom zobrazim info "je toho vela"
( tu uz budem potrebovat pocitat riadky na web/app-serveri, to je ale pri uvedenych poctoch zanedbatelne ) -
> to se většinu asi nevyplatí.
To si musite otestovat sam :-)
Zalezi to od povahy aplikacie. Ak mam databazu na rovnakom stroji ako WEB-server a male tabulky, ktore aj s datami vojdu do cache db-servera, tak sa to skutocne neoplati.
Ak vsak s databazou komunikujem cez siet, v tabulke mam 100 milionov zaznamov a k tomu komplikovanu where-klauzulu tak to zacne byt o niecom inom ....
Ten "select count(*)" dokaze poriadne zabit db-server. -
Moje trocha: v pripadech, kdy je celkovy pocet vysledku zajimavy, by ve skutecnosti navstevnikovi stacil odhad - neboli neni nutne provadet zamykani nebo transakce, lze prohlasit ze cislo, ktere uzivatel dostane, bude dost presne pro jeho potrebu i kdyz dojde zaroven k insertu.
Konecne, stejne neni mozne transakci ani zamkem udrzet konzistenci v dobe, kdy si uzivatel prohlizi stranku (a aplikace na serveru vlastne nebezi). -
Lampa (neregistrovaný)%subj% uz napouzivam docela dlouho, protoze v nem byla nekdy nejaka chyba.
lepsi je dle meho pouzit pro vyber (pri pouziti limit) o jeden zaznam vice a do podminky dat toto:
$limit = 20;
$sql = 'SELECT * FROM tabule WHERE podminka LIMIT '.($limit + 1);
$i = 0;
if ($line = fetchrow) {
do {
$i++;
// proved neco se zaznamem
while (($line = fetchrow) && $i < $limit);
} else
echo 'nic neni';
v $i mam pocet zaznamu, ktere jsem zobrazil(kdyz se zrusit podminka s limitem v sql a we while, tak mam vsechny radky) -
... (neregistrovaný)do { } nedoporucuji pouzivat, protoze kdyz nastavite spatne podminky, aplikace se muze zacyklit, neni to moc dobre... Tomas
-
Dave (neregistrovaný)Tak jsem zkusil pouzit posledni zpusob, do ted jsem vzdy pouzival count(*) a pak normalni select se stejnou podminkou. A musim rict at je to jakkoliv, tak me to jede 2x rychleji kdyz necham svoje reseni, zatim co SQL_CALC_FOUND_ROWS je pomale. Tabulka nad kterou to jezdi ma zhruba 40tis zaznamu, web ma 70tis sessions/den a zobrazeni 1,5mil/den. Tim se nechci chlubit, ale vzorek pro zatez dostatecny. Kdyz sem to nahodil prvne, zhrotila se cela databaze a load stoupnul 20x.
-
Marabu (neregistrovaný)A máte tam ten limit? Jde o to, že se tohle používá s LIMIT a SQL_CALC_FOUND_ROWS vám vrátí počet řádků, jaký by byl bez limitu - tzn. nezjišťujete počet řádků a pak pracujete s limitem, ale uděláte to v jednom příkazu. Pokud jste tam ten limit nedal, ani se nedivím že jste složil DB ;)
-
barney (neregistrovaný)vo vseobecnosti by vyhodnejsim zapisom mal byt 'count(primary_key)' ... * totiz znamena vsetky stlpce, co moze znamenat, ze db server natiahne do pamate cele riadky a az potom spusti agregatnu funkciu. (samozrejme predpokladam ze primary_key je int/bigint)
to, ze count sa malokedy pouziva na celu tabulku ale v suvislosti s inymi parametrami (ci uz WHERE alebo GROUP BY napriklad) uz bolo spomenute :-)) -
Bylo by naivní myslet si, že COUNT(*) funguje tak, že databáze do paměti natáhne celou tabulku a následně spočte řádky. Takovéto konstrukce jsou samozřejmě optimalizované. Záleží ale na konkrétní databázi, co je rychlejší a co pomalejší - jak už jsem psal, tak COUNT(id) je pokud vím rychlejší než COUNT(*) např. ve starších verzích Oracle, v jiných databázích to může být zase naopak. MySQL je optimalizované na COUNT(*) (jak ukazují třeba příklady v MySQL dokumentaci), ale COUNT(id) mu problémy dělat jistě taky nebude.
-
Ono také jde o to, co COUNT přesně počítá, jak databáze zachází s transakcemi a podobně, že. Například důvod, proč Firebirdu nestačí ke spočítání řádků scan nějakého indexu je verzování řádků. Důvodem, proč ke spočítání COUNT(sloupec) nestačí scan indexu i bez verzování a třeba i bez transakcí je zase ten, že COUNT(sloupec) musí ignorovat NULL hodnoty. Takže COUNT(id) je principielně spíš o dost náročnější než COUNT(*), alespoň na disk fetche a u tabulek s hodně sloupci.
Nebo jsem něco špatně pochopil?
ČLÁNKY DO MAILU