lekérdezés futási idejének megállapítása

Adatbázis: SQL, XML DB

Sziasztok!

Szerintetek melyik a gyorsabb?
SELECT count(mezonev) FROM tablanev WHERE mezonev = 123;
vagy
SELECT count(*) FROM tablanev WHERE mezonev = 123;

Próbálnám gyorsítani és optimalizálni a dolgokat, de ha konzolon nézem egy 20000 rekordot tartalmazó táblán, mind a kettő ugyanazt az időeredményt adja.(0.04 sec)

De fontos lenne, hogy a gyorsabb(optimálisabb) verziót válasszam, mert elég sokszor hajtódik végre a lekérdezés.

Előre is köszi a válaszokat.

  • 6112 megtekintés

( mocsi | 2012. 01. 10., k – 08:47 )

Legalább mondj egy RDBMS típust és verziót. A régi MYSQL (3,23) Az első verzió esetén gyorsabb volt valamivel.

( turdus | 2012. 01. 10., k – 08:56 )

szerintem
SELECT SUM(1) FROM tablanev WHERE mezonev = 123;

biztos, mert nem vacakol mezőkkel, adatokkal, referenciákkal stb., csak konstans szerepel benne.
Egyébként meg méréshez (pl php-ben, de írhatod bármi másban is):

$start=microtime(true);
mysql_query(...);
$end=microtime(true);
echo($end-$start)."μsec");

Persze érdemes többször futtatni, és kiátlagolni a mérési eredményeket.

( asch v | 2012. 01. 10., k – 12:29 )

Query plan-t nem lehet valahogy megnézni? Abból látszik, hogy milyen műveleteket fog csinálni az adatbázis-kezelő.

A futásidő mérés felbontásának pontosságát növelni módszerek:
* Mindenképpen mérj annyi adaton, amennyi az adatbázisban éles üzemben lesz. Meg egy kicsit többön is. Mágikus határok átlépésekor nagyon meg tud változni a válaszidő.
20000 kevésnek tűnik.
* Még ha nem is lesz annyi adatod soha, akkor is növeld a teszt adatbázis méretét addig, hogy a mérési hiba kicsi legyen a mért értékhez képest.
* Meg lehet próbálni a válaszidő helyett a szerver processz CPU felhasználását monitorozni. Írj programot, ami egyszerre sok kérést indít, és azzal mérj. A CPU használat görbét nézd (illetve ha nem fér memóriába az adatbázis, akkor a diszk IO-t is)! Életszerűbb teszt, mint egyetlen futás eredménye.

( fhuse | 2012. 01. 10., k – 12:48 )

Nem tudom mennyire lesz statikus a query/tábla,
de esetleg eltárolni minden mezonev-re az eredményt, és onnan lekérdzni?

( Jason v | 2012. 01. 10., k – 13:02 )

Mivel a MyISAM nem tranzakciós, tárolja a sorok számát, így a count(*) azt olvassa ki). Ha a mezőnév PK, akkor ugyanez, ha sima index, akkor az index számosságát adja vissza.
INNODb meg index számosságot vagy table scant eredményez, ha jol emlekszem.

Ha szűrsz is (mint most teszed), akkor ha a mezonev indexelt, akkor azt szamolja, amugy meg teljes szortirozas utan megszamolja mennyi sor maradt.

(Próbáld ki, pármillió sorral pl.)

Igy a problemad eltolodott COUNT() optimalizalasrol helyes indexkezelesre.

( cadmagician | 2012. 01. 10., k – 15:54 )

SQL_CALC_FOUND_ROWS found_rows()-val?

SELECT SQL_CALC_FOUND_ROWS mezonev FROM tablanev WHERE mezonev = 123;
select found_rows() as darab;

( szabi2k v | 2012. 01. 10., k – 16:57 )

Mivel 0.04 a futasi ido szerintem tul keves adatod van, hogy ossze tudd hasonlitani.
Ha a mezonev nem lehet NULL, akkor ugy tudom, hogy mind a ketto ugyanannyi ido alatt fut le.
Ha mezonev lehet NULL, akkor a ket eredmeny nem biztos, hogy egyenlo, ugyhogy attol fugg, hogy melyik ertek erdekel.

Ha csak a sorok szama erdekel, akkor a SQL_CALC_FOUND_ROWS-os modszer pocseklas szerintem, mert kiszedi neked a mezonev oszlopot, foloslegesen.

Ezenkivul vigyazz meresekkor a mysql query cache-re, a masodik futtataskor jo esellyel (ha nem modosult a tablanev tabla) nem futtatja le a query-t, hanem kiveszi a cache-bol az eredmenyt. Ugyhogy az 123-t minden futtataskor csereld mas ertekre.

( meridian v | 2012. 01. 10., k – 19:16 )

köszönöm a segítséget, a doksi, válaszok és tesztek alapján mivel a tábla myisam típusú így maradok a második verziónál... ha változtatok újragondolom a dolgokat..