MySQL a použití sloupce ID

Logik

  • *****
  • 881
    • Zobrazit profil
    • E-mail
Re: MySQL a použití sloupce ID
« Odpověď #30 kdy: 10. 05. 2011, 14:55:28 »
V postgreSQL je podobný mechanismus,
http://www.postgresonline.com/journal/archives/10-How-does-CLUSTER-ON-improve-index-performance.html
ale musí se to dělat částečně manuálně.


Kit

Re: MySQL a použití sloupce ID
« Odpověď #31 kdy: 10. 05. 2011, 21:57:20 »
No, s většinou jsem možná přestřelil, ale Innodb to tak má
http://me.in-berlin.de/doc/mysql-doc/manual_InnoDB.html
(hledej clustered index)
Podle tohoto zdroje je primární index vytvářen vždy. Tedy i v případě, že není explicitně definován. Data jsou součástí B-stromu, s velkou pravděpodobností je tedy snížen počet čtení diskových bloků. Fyzické řazení dat na disku však nemusí být úplně sekvenční ani při postupném zvyšování (např. syntetického) primárního klíče. Efektivita uložení (a následného vyhledávání) dat s použitím syntetického nebo monotónního klíče je však vyšší.

Ohledně obsazení paměti je tedy jedno, jestli deklaruji nebo nedeklaruji primární klíč. Pokud ho deklaruji, mám k němu z aplikace přístup. Je tedy výhodnější ho deklarovat.

Logik

  • *****
  • 881
    • Zobrazit profil
    • E-mail
Re: MySQL a použití sloupce ID
« Odpověď #32 kdy: 11. 05. 2011, 12:14:14 »
RowId je innodb vždy, i když je definován primární klíč, akorát neviditelně. Pokud je definován unique klíč a ne primární klíč, je clusterován ten unique klíč - ale tady jsme se bavili o rozdílu složený versus jednoduchý pkey. Deklarace tedy zabere více místa na disku (a tedy i v paměti).

Co se týče vyhledání dat, tak ta se budou vždy vyhledávat podle indexu a zajímat nás budou pouze data z indexu, takže je vyhledávání stejně rychlé s existencí i bez existence autoinkrementního políčka (v Mysql).

Co je výhodnější pro updaty je ale vlastně otázka, protože sice update clusterovaného indexu je jednodušší s jednoduchým klíčem, ale zas tam je o index navíc...

devnull

Re: MySQL a použití sloupce ID
« Odpověď #33 kdy: 25. 05. 2011, 00:42:30 »
A pokud mi je sloupec s auto increment ID k nicemu a v aplikaci ho nepouziju a mam moznost jednoznacne identifikovat radek tabulky pomoci jineho klice (treba slozeneho z vice sloupcu), tak se muzu na ID vykaslat a MySQL s tim NEMA nejmensi problem. A pokud nekdo tvrdi ze ma, tak at laskave odkaze na nejakou analyzu.

On se generovanej klic muze leckdy hodit. Treba kdyz mam tabulku kde PK by mohl byt nejaky sloupec - treba VARCHAR(100) - tak kdyz budu se budu na tuto tabulku v dalsich x tabulkach odkazovat, tak je sakra rozdil jestli to bude pres VARCHAR(100) nebo INT. Krome velikosti dat v tabulkach mi take narostou indexy, a vsechno zabere vic pameti a bude pomalejsi.