Hlavní navigace

Připojení k Internetu

Jak se měří internet pomocí sond

Názory k článku
PHP okénko: Získání počtu řádek

Jakub Hegenbart aura:84
30. 3. 2005 0:13 Nový

PHP okénko?

celé vlákno
"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í?
HKMaly aura:99

Re: PHP okénko?

celé vlákno
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.
uživatel si přál zůstat v anonymitě
30. 3. 2005 1:33 Nový

Re: PHP okénko?

celé vlákno
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...
uživatel si přál zůstat v anonymitě
30. 3. 2005 1:33 Nový

Re: PHP okénko?

celé vlákno
(A zase ty uvozovky... :/)
HKMaly aura:99

Re: PHP okénko?

celé vlákno
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.
Jakub Hegenbart aura:84
30. 3. 2005 2:45 Nový

Re: PHP okénko?

celé vlákno
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ší? :)))
Jakub Hegenbart aura:84
30. 3. 2005 2:47 Nový

Re: PHP okénko?

celé vlákno
Nerad se opakuju, ale podpora češtiny na tomto serveru je opravdu mizerná, pokud je člověk z práce přivyklý korektní typografické úpravě :///
Adam Hauner aura:100

Re: PHP okénko?

celé vlákno
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ší?
Jakub Hegenbart aura:84
30. 3. 2005 9:02 Nový

Re: PHP okénko?

celé vlákno
Mám pocit, že na adresu redakce@root.cz jsem to už jednou (před pár týdny snad) psal a nikdo neodpovídal. Tak jsem to vzdal. Ale možná se pletu, zkusím se mrknout do pošty, ale nevím, do které bych se vlastně měl podívat... :)
uživatel si přál zůstat v anonymitě
30. 3. 2005 12:36 Nový

Re: PHP okénko?

celé vlákno
$nazor = ereg_replace ("&(#[[:digit:]]+;)", "&\\1", $nazor); Člověk by řekl, že na serveru s "PHP okénky" napsat regulární výraz někdo zvládne...
Marabu
Marabu (neregistrovaný)
30. 3. 2005 12:39 Nový

Re: PHP okénko?

celé vlákno
A není snazší s názorem místo speciální práce s jednotlivými znaky provést nějakou analogii $nazor = ereg_replace ("&(#[[:digit:]]+;)", "&\\1", $nazor);
mat
mat (neregistrovaný)
30. 3. 2005 8:53 Nový

Proboha ja ten scrollovaci zdrojak nepreziju.

celé vlákno
Proc se ten zdrojak tak debilne scrolluje? To je hruza. Serialek je jinak pekny, ale kdysi baly radost se na root i "jen tak divat". Dneska rychle precist a pryc :-(
mat
mat (neregistrovaný)
30. 3. 2005 8:55 Nový

Proboha ja ten scrollovaci zdrojak nepreziju.

celé vlákno
Proc se ten zdrojak tak debilne scrolluje? To je hruza. Serialek je jinak pekny, ale kdysi baly radost se na root i "jen tak divat". Dneska rychle precist a pryc :-(
mat
mat (neregistrovaný)
30. 3. 2005 8:56 Nový

Proboha ja ten scrollovaci zdrojak nepreziju.

celé vlákno
Proc se ten zdrojak tak debilne scrolluje? To je hruza. Serialek je jinak pekny, ale kdysi baly radost se na root i "jen tak divat". Dneska rychle precist a pryc :-(
mat
mat (neregistrovaný)
30. 3. 2005 10:16 Nový

Re: Proboha ja ten scrollovaci zdrojak nepreziju.

celé vlákno
omlouvam se nevim jak se to tam vlozilo 3x
pharook
pharook (neregistrovaný)
30. 3. 2005 11:36 Nový

Re: Proboha ja ten scrollovaci zdrojak nepreziju.

celé vlákno
Protože by se jinak musela horizontálně scrollovat celá stránka, což může podstatně větší otrava?
Michal Kubeček
Michal Kubeček (neregistrovaný)
30. 3. 2005 11:22 Nový

Re: PHP okénko?

celé vlákno

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é…

HKMaly aura:99

Re: PHP okénko?

celé vlákno
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
Satano (neregistrovaný)
30. 3. 2005 23:27 Nový

Re: PHP okénko?

celé vlákno
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).
martin
martin (neregistrovaný)
31. 3. 2005 8:58 Nový

Re: PHP okénko?

celé vlákno
Tak to bych chtěl ty vaše deadlocky vidět. Explicitní zamykání celých tabulek přece při použití transakcí není potřeba. Zkuste blíž popsat svůj problém, příčinu bych hledal spíš mezi židlí a klávesnicí.
Satano
Satano (neregistrovaný)
1. 4. 2005 21:37 Nový

Re: PHP okénko?

celé vlákno
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).
Jakub Hegenbart aura:84
1. 4. 2005 23:44 Nový

Re: PHP okénko?

celé vlákno
Otázka je, zda v dané aplikaci je výhodnější dopustit občasný row-level deadlock nebo narvat konkurenční požadavky na různé řádky do jediné čekající fronty...
Vladimir Kralik
31. 3. 2005 10:49 Nový

Re: PHP okénko?

celé vlákno
> 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 ?
HKMaly aura:99

Re: PHP okénko?

celé vlákno
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.
Jakub Hegenbart aura:84
1. 4. 2005 19:36 Nový

Re: PHP okénko?

celé vlákno
Proč by při zamykání tabulek mělo docházet k deadlocku? Tabulky se zamykají najednou a na začátku transakce, v podstatě atomicky, a očekával bych, že za takových okolností dojde k deadlocku dost obtížně :)
Vladimir Kralik
4. 4. 2005 9:37 Nový

Re: PHP okénko?

celé vlákno
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.
Jakub Vrána aura:60
4. 4. 2005 12:23 Nový

Re: PHP okénko?

celé vlákno
Např. v MySQL je nutné všechny tabulky zamknout najednou. Druhý LOCK způsobí odemknutí předchozích zámků.
Jakub Vrána aura:60
30. 3. 2005 8:01 Nový

Re: PHP okénko?

celé vlákno
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.
Jakub Hegenbart aura:84
30. 3. 2005 9:04 Nový

Re: PHP okénko?

celé vlákno
"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!"."

A to se vylučuje? To jsou zcela nezávislá tvrzení!
Jakub Vrána aura:60
30. 3. 2005 9:38 Nový

Re: PHP okénko?

celé vlákno
Ano, to se vylučuje. Když o něčem napíšete, že to je "Brutálně MySQL-specifická optimalizace. Jinde nepoužitelná.", tak tím říkáte, že nikde jinde to takhle nefunguje. Což jednak není pravda a jednak to sám přiznáváte v druhém příspěvku.
Jakub Hegenbart aura:84
30. 3. 2005 10:48 Nový

Re: PHP okénko?

celé vlákno
Můžete mne odkázat na konkrétní výrok, kde to přiznávám? Nějak jsem to nepochopil...
Jakub Hegenbart aura:84
30. 3. 2005 9:05 Nový

Re: PHP okénko?

celé vlákno
"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!"."

A to se vylučuje? To jsou zcela nezávislá tvrzení!
Jakub Hegenbart aura:84
30. 3. 2005 9:06 Nový

Re: PHP okénko?

celé vlákno
"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!"."

A to se vylučuje? To jsou zcela nezávislá tvrzení!
Jakub Hegenbart aura:84
30. 3. 2005 9:09 Nový

Re: PHP okénko?

celé vlákno
A k...rucinál. Omlouvám se za multipost, ale máme teď na síti asi minutové lagy a člověk neví, jestli je to vypadlé spojení nebo jen opožděné pakety :((((
Michal Kubeček
Michal Kubeček (neregistrovaný)
30. 3. 2005 11:25 Nový

Re: PHP okénko?

celé vlákno
Problém je v tom, že pokud má vaše transakce úroveň izolace read committed (která je poměrně obvyklá), může proběhnout mezi vašimi dvěma selecty v jiné transakci insert i commit.
Jakub Vrána aura:60
30. 3. 2005 11:31 Nový

Re: PHP okénko?

celé vlákno
Bohužel není patrné, o kterých dvou selectech mluvíte. Pokud máte na mysli jeden dotaz pro získání počtu řádek a druhý pro získání dat, tak to je v článku rozebráno a je v tomto případě doporučeno použití pouze jednoho dotazu a funkce mysql_num_rows().
Michal Kubeček
Michal Kubeček (neregistrovaný)
30. 3. 2005 22:31 Nový

Re: PHP okénko?

celé vlákno
Ve třetím okénku u posledního příkladu (první dva jsou označeny jako neefektivní) vidím dva selecty. To je IMHO velmi častá situace: zobrazuji jednu stránku, ale pro stránkovací odkazy potřebuji znát celkový počet položek.
Jakub Vrána aura:60
30. 3. 2005 23:00 Nový

Re: PHP okénko?

celé vlákno
Počet řádků se pochopitelně zjistí a někam poznamená už při položení prvního dotazu, druhý dotaz slouží jenom pro získání tohoto počtu.

Je to analogické mechanismu INSERT + SELECT LAST_INSERT_ID(). INSERT někam poznamená ID vloženého záznamu a SELECT LAST_INSERT_ID() toto ID získá.
Michal Kubeček
Michal Kubeček (neregistrovaný)
30. 3. 2005 23:23 Nový

Re: PHP okénko?

celé vlákno
Z těchto věcí mi tak trochu běhá mráz po zádech. Doufám, že je aspoň jasně zdokumentováno, jestli se to udržuje per transaction, per connection, nebo jak vlastně.
Satano
Satano (neregistrovaný)
30. 3. 2005 23:08 Nový

Re: PHP okénko?

celé vlákno
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.
Vladimir Kralik
30. 3. 2005 9:32 Nový

Preco zistovat pocet riadkov ?

celé vlákno
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.
Jakub Vrána aura:60
30. 3. 2005 10:02 Nový

Re: Preco zistovat pocet riadkov ?

celé vlákno
"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."
Vladimir Kralik
30. 3. 2005 11:00 Nový

Re: Preco zistovat pocet riadkov ?

celé vlákno
> Š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
Jan Mensik (neregistrovaný)
30. 3. 2005 11:20 Nový

Re: Preco zistovat pocet riadkov ?

celé vlákno
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.
Vladimir Kralik
30. 3. 2005 12:05 Nový

Re: Preco zistovat pocet riadkov ?

celé vlákno
> 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 )
Jakub Vrána aura:60
30. 3. 2005 12:13 Nový

Re: Preco zistovat pocet riadkov ?

celé vlákno
No, získávat 201 řádek kvůli dvaceti a ještě s tím, že přijdu o informaci o celkovém počtu záznamů, to se většinu asi nevyplatí.
Vladimir Kralik
30. 3. 2005 12:28 Nový

Re: Preco zistovat pocet riadkov ?

celé vlákno
> 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.
HKMaly aura:99

Re: Preco zistovat pocet riadkov ?

celé vlákno
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).
puco
puco (neregistrovaný)
30. 3. 2005 9:55 Nový

Pridanie nalepky

celé vlákno
Rozhodne by sa zislo aby sa tomu clanku pridala aj nalepka MySQL a teda aby tie nalepky maly nejaky zmysel.
Jakub Vrána aura:60
30. 3. 2005 11:13 Nový

Re: Pridanie nalepky

celé vlákno
Díky za podnět, nálepka byla přidaná. Ale příště ho pošlete prosím buď redakci nebo autorovi na e-mail, diskuse se tím zbytečně znehodnocuje.
Lampa
Lampa (neregistrovaný)
30. 3. 2005 12:55 Nový

mysql_num_rows

celé vlákno
%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ý)
6. 12. 2005 8:35 Nový

Re: mysql_num_rows

celé vlákno
do { } nedoporucuji pouzivat, protoze kdyz nastavite spatne podminky, aplikace se muze zacyklit, neni to moc dobre... Tomas
Lampa
Lampa (neregistrovaný)
6. 12. 2005 9:16 Nový

Re: mysql_num_rows

celé vlákno
no to je u kazdeho cyklu ne ?

takze to je zakladni podminka, ze v do je podminka spravne (jako v jinem cyklu)
Dave
Dave (neregistrovaný)
30. 3. 2005 14:51 Nový

Zkouska "triku"

celé vlákno
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
Marabu (neregistrovaný)
30. 3. 2005 15:46 Nový

Re: Zkouska "triku"

celé vlákno
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 ;)
Dave
Dave (neregistrovaný)
1. 4. 2005 23:07 Nový

Re: Zkouska "triku"

celé vlákno
Jiste ze sem tam mel limit na konci :-)...normalne mi to fungovalo, ale jak sem to nahodil vsem, tak to selhalo, kdyz sem to testoval sam, bylo to "jen" pomalejsi. Nechapu to. Dave
barney
barney (neregistrovaný)
30. 3. 2005 16:02 Nový

count vseobecne

celé vlákno
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 :-))
Jakub Vrána aura:60
30. 3. 2005 16:19 Nový

Re: count vseobecne

celé vlákno
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.
Jakub Hegenbart aura:84
1. 4. 2005 19:51 Nový

Re: count vseobecne

celé vlákno
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?
HKMaly aura:99

Re: count vseobecne

celé vlákno
Mno ... pokud je id definovane jako SMALLINT UNSIGNED NOT NULL, tak lze predpokladat ze v nem NULL nebude, ne ?
Zasílat nově přidané příspěvky e-mailem