ugrás a tartalomhoz

MySQL Optimization

Török Gábor · 2005. Jún. 14. (K), 17.23
Jeremy Zawodny fóliái a MySQL optimalizálási lehetőségeiről
 ■
1

tranzakció

Hodicska Gergely · 2005. Jún. 16. (Cs), 18.32
Sziasztok!


Ezt írja egy helyen:
Use transactions
  • Prevents data loss
  • Server does less random I/O
  • Performance and reliability

Ebből a második vajon mit fed? Nézegettem doksi idevágó részeit, de nem talatám semmi olyan utalást, ami erre magyarázatként szolgálna.

Amúgy érdemes átlapozni, van benne pár jó ötlet.


Felhő
2

Memóriában az adatok

Török Gábor · 2005. Jún. 16. (Cs), 19.29
Szerintem azt, hogy a tranzakciók során valamennyi módosítás a memóriában történik, így csupán a lekérdezések alkalmával kell a lemezhez nyúlni, ez pedig lemezműveletek szempontjából kevesebbe kerül. Az én olvasatomban a dokumentáció is ezt sugallja:

After disabling autocommit mode by setting the AUTOCOMMIT variable to zero, you must use COMMIT to store your changes to disk or ROLLBACK if you want to ignore the changes you have made since the beginning of your transaction.


--
slink
http://20y.hu/
5

Log?

Hodicska Gergely · 2005. Jún. 17. (P), 11.09
Hát ez is lehet, bár nekem az lenne logikus, hogy a tranzakciókezelés kapcsán inkább több adatott kell tárolni, ráadásul más adatbázis kezelők esetén bevett szokás, hogy a tranzakció során (mielőtt ténylegesen kiíródna a lemezre) készül egy log, ami alapján, ha a kiírás alatt gond lenne, a késöbbiek során visszaállítható a tranzakció. Ha pedig ezt logot nem sikerül már kiírni, akkor az egyből rollback.


Felhő
3

random i/o

Bártházi András · 2005. Jún. 16. (Cs), 21.46
A random jelentése itt a RAM rövidítésben használttal egyezik, azaz a "véletlenszerű" itt azt jelenti, hogy a meghajtón fel-alá olvasott és írt adatokból, röviden a lemezműveletekből van kevesebb.

-boogie-
4

Köszi ;)

Hodicska Gergely · 2005. Jún. 17. (P), 11.05
Szia!


Oké, de pont az érdekelne, hogy ez miért van. Lásd Gáborhoz írt válaszom.


Felhő
6

Writing fast query

Hodicska Gergely · 2005. Jún. 17. (P), 16.27
Az egyik ilyen jelű fólián az egyik pont a UNIONs. Gondolom itt a arra gondol, hogy ha a szituáció megengedi, akkor inkább használjunk UNION-t, mintsem mondjuk két lekérdezést. Vagy lehet egyég előnye is?


Felhő
7

Mikor kell NOT NULL?

Török Gábor · 2005. Jún. 18. (Szo), 11.54
A Database Design szekcióban olvasható a "Use NOT NULL where it makes sense" pont. Tehát csak akkor használjuk ezt, ha valóban szükséges. Nagyon sok szakkönyv viszont ezt a megszorítást valamennyi oszlophoz szinte kötelezőnek javasolja. Egyfelől értem, hogy miért lehet felesleges, ha a fölötte lévő alkalmazás réteg egyértelműen biztos, hogy fog adatot továbbítani adott mezőbe, másfelől hanyagságnak tartom egy másik rétegre való támaszkodást, különösen, ha azt nem mi kódoljuk (de attól sem lesz 100%-ig biztos). Szerintetek hol érdemes meghúzni a határt?

--
slink
http://20y.hu/
8

Félreértés?

Hodicska Gergely · 2005. Jún. 20. (H), 00.49
Szia!


Szerintem ő is azt akarja sugallni, hogy ahol csak lehet, használjuk a NOT NULL megszorítást.

Én szeretem, ha az ilyen jellegű megszorítások már az adatbázis tervben is megjelennek. Jobb ha már maga az adatbázis képes biztosítani az adatok konzisztenciáját. (Az persze egy másik dolog, hogy ezt igazából egy MySQL esetén nem áll módunkban tisztességesen megtenni, különböző ehhez szükséges funkciók hiánya miatt. Az 5-ös verziótól még tekintsünk el.)

Plusz másik szempont, hogy teljesítméy szempontjából is számít, hogy haszánljuk-e ezt a megszorítást:
  • Egy NULL oszlop esetén az adatbázis kezelőnek (általában) külön tárolnia kell a mezőn kívül, hogy a mező értéke NULL-e, ami plusz munka.
  • Ezenkívül pl. adatbázis kezelőtől függően előfodul, hogy nem mindegyik index típus támogatja a NULL értékek tárolását, így ha épp ilyen indexünk van, és mondjuk rendezzük a táblát az adott oszlop szerint, vagy épp összekapcsoljuk egy másik táblával, akkor az index nem kerül használatra, a teljes táblát végig kell olvani.

Ja és még egy apróság, hogy mindig érdemes kiírni akár a NULL-t, akár a NOT NULL-t, mert a különböző adatbázis kezelők esetén eltérő lehet, hogy melyiket tekinti alapértemezettenk, ha nem adjuk meg. Így egyértelmű lesz, hogy mit is szeretnénk.


Felhő