Optimalizace dotazů

Co je rychlejší ?
Udělat 10 dotazů s WHERE a vytáhnout tak 10 informací nebo udělat kompletní výcuc a pak to vytáhnout v php? Úplně nejlepší bude asi za WHERE se všema deseti parametrama.
Celkově mě chybí to pozadí, co se děje za mysql_query, takže jenom laicky spekuluju :(
Nemáte na toto někdo nějakej článek, případně radu?

Můj názor je, že pokud to je možné, tak raději udělat jeden dotaz a data vytáhnout v PHP. Problém často bývá, že SQL server bývá dost zatížený (třeba tady na WZ) a posílat tam spoustu dotazů, by mělo v principu trvat déle než jeden složitější dotaz. SQL server bývá často také fyzicky jiný stroj, takže vlastně vyvoláváš komunikaci mezi dvěma počítači a to také trvá.

Jiří Janák: udělat jeden dotaz ve kterém budeš mít jenom to, co potřebuješ.

jestli je to z jedné tabulky, tak vem těch 10 dotazů, z nich podmínky z where a pak stvoř jeden dotaz, kde bude těchto 10 podmínek. Neboj SQL to zvládne.
Př.:
select cosi from t where x=1;
select cosi from t where x=2;
...
jako
select cosi from t were x=1 or x=2;

neznám konkrétní problém, tak se konkrétněji odpovědět nedá...

ZBI: díky za myšlenku s dvěma stroji
Tom, Marek: takže to, co jsem říkal (viz. "Úplně nejlepší bude asi za WHERE se všema deseti parametrama.", i když to asi není nejlíp formulovaný, myslel jsem tím, to co jste odpověděli).

Kdyby jste přece jenom věděli něco víc o pozadí toho volání (přápadně nějakej benchmark), tak bych se rád poučil :) Ale to už asi bude na úrovni parseru...

Já se spíš přikláním k Tomovi. Čím míň dat se tahá odkudkoli kamkoli, tím líp. Separovat data až v PHP je, podle mě, kravina. Akorát se tím víc zatíží SQL server. Přece jenom musí ty data odněkud vzít a to znamená z disku. A na disk je přístup pomalý.
Když stvořím dotaz, který z tabulek vybere jenom to potřebné, je to to nejlší, co pro výkon SQL můžu udělat.
Zbi, odeslání 10 dotazů je daleko méně zatěžující než si nechat poslat kýbl dat, které pak třídíš v PHP.
Není to tak jednoduché téma a podle zdejšího, věčně hodně zatíženého SQL serveru, je vidět, že ne každý tohle zvládá.
I když, jak optimalizovat dotazy třeba z phpBB nevím.

..ještě k tomu jinému stroji. To je spíš výhoda, než nevýhoda. Pokud jsou třeba webserver a SQL server spojené 1G linkou (což dneska není nic zvláštního), tak to může být i rychlejší jak tahat z disku na jednom stroji... (myšleno, že tahle linka už je rychlejší jak disky, takže nezdržuje)

Marek z Markova: "I když, jak optimalizovat dotazy třeba z phpBB nevím." já ano: označit a klávesa DELETE. Jediné účinné řešení ;) Ne, vážně: optimalizovat SQL pro skript, který všeobecně stojí za dvě věci je zbytečné. S optimalizací bych začal u PHP části aplikace a zároveň postupně optimalizovat SQL.

Jinak jsi si dovolil trošku poupravit tvůj výčet zbytečných operací (viz ten kýbl dat [ pozn. super hláška, tu si zapamatuju :) ])
1) Poslat jednoduchý dotaz => výborné pro líného programátora
2) SQL server musí najít kýbl dat => ztráta času a výkonu
3) procpat kýbl dat na HTTP server => ztráta času
4) pomocí PHP vytřídit potřebná data od balastu => brutální ztráta času a výkonu (nedejbože přetečení memory_limitu)
5) vybafnout s daty na uživatele, nebo co s nimi zamýšlíš ...

Krásné, že?

No a k tomu oddělenému serveru: fyziky oddělený SQL server je dnes již standart, "spojený server" (tedy jeden PC s např. Apachem, PHP a MySQL) se dnes používá pouze na málo vytěžované aplikace (třeba servery malých intranetových síťí). No a proč se používají dva stroje místo jednoho? Protože se zátěž rozloží na 2 počítače, kdy se na jednom (na HTTP serveru) peče procesor, protože nějakej blbec zacyklil skript, nebo se sem hrubou silou snaží nabourat tupí hackeři a na druhém s v klidu přede databáze a čas od času vrátí pár kb dat. Povětšinou si "sedí" pěkně vedle sebe spojení 1GB linkou a je jim hej.

Podle mne je mnohem dulezitejsi optimalizovat SQL nez PHP, a to nekolika zakladnimi vecmi:

1) pouzivat JOIN namisto WHERE tam, kde je to mozne

2) jeden slozitejsi dotaz je lepsi nez 2 jednodussi (samozrejme to neplati vzdy)

3) pouzivat LIMIT, pokud vysledky strankuji

4) zalozit INDEX nebo FULLTEXT na vyhledavani

5) misto "WHERE x=5 OR x=10" napsat "WHERE x IN (5,10)"

6) pokud taham data z tabulek o mnoha radcich, nechat si vracet jen ty sloupce, ktere opravdu potrebuju (tj. nepouzivat SELECT *)

To je asi to zakladni ;-)

tohe (strelka.unas.cz)
To mas z nejake stranky?

Logicky join bude slozitejsi nez where, ale silne zalezi na indexovani a strukture tabulky.
Autoincrement integer(11) se bude indexovat mnohem rychleji nez jmeno varchar(16) a timpadem na integer bude jiste rychlejsi where.

"2) jeden slozitejsi dotaz je lepsi nez 2 jednodussi (samozrejme to neplati vzdy)"
souhlas
treba s tim join mas slozitost n*n proti dvou dotazum po sobe n+n , ale zalezi na typu dotazu

3) , 4)
100%

"5) misto "WHERE x=5 OR x=10" napsat "WHERE x IN (5,10)" "
tak to nevim, pisi to tak, ale spise proto, ze tam mam 5,10,11,20,300 atd :)

" 6) pokud taham data z tabulek o mnoha radcich, nechat si vracet jen ty sloupce, ktere opravdu potrebuju (tj. nepouzivat SELECT *) "
Spis bych to upravil, ze pokud taha hodne dat o velke velikosti, tak vybirat sloupce.

Treba u tabulky
jmeno(16) heslo(40) pohlavi(1) datumprihlaseni(10) datumregistrace(10)
nema smysl pouzivat sloupce, zrovna cely radek

Ale, jestlize chci vypsat jen nadpisy prvnich 20 clanku
jmeno(16) nadpis(40) clanek(1000)
je zbytecne tahat sloupce i s clankem

A s tim PHP podle mne take nemas uplne pravdu, v PHP bys mel optimalizovat vypisovani tak po blocich 2-20k, protoze cyklus, ktery ti vypisuje 20x
echo "nadpis"
echo "jmeno"
echo "clanek"
tady dojde k tomu, ze server si to rozdeli a pak musi znova zavolat SQL nebo najit si rozpracovany dokument a poslat ti dalsi casti. Tim padem to proste znova zacne zpracovavat, co uz ma, nema a tak a cele se to zbytecne zdrzuje. jednodussi je to ulozit do promenne a pak naraz vypsat. server pak posila vysledek z pameti a nemusi nic rozpracovavat znova