Začínáme s MySQL 15. – Zámky a klíče

Diskuze čtenářů k článku

Dusan Bolek  |  07. 12. 2001 08:37  | 

Ve skutecnych databazich se nerovna klic (key) a index. Mam dojem ze v tom ma autor trosku gulas, protoze tyhle dva pojmy zamenuje. I kdyz jak to vypada tak v MySQL to tak skutecne funguje. Nicmene obecne key != index.
BTW: Mam prvni cast clanku pochopit tak, ze v MySQL si musi uzivatel sam programovat zamykani ?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pavel Cvrcek  |  07. 12. 2001 14:56  | 

Dobry den,

autor v tom gulas nema. Tento clanek je o MySQL! Snazil jsem se to vysvetlit lidem, kteri MySQL nikdy zvlast nepouzivali nejak srozumytelne. Kdyz se to vezme obecne, tak mate pravdu. Klic != index.

Autor clanku

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dusan Bolek  |  07. 12. 2001 15:22  | 

No uz jsem slysel i lepsi vymluvy. To ze konkretni produkt nepodporuje nejakou feature jeste neznamena, ze je mozne ignorovat obecne uznavane nazvoslovi. Krome toho byva zvykem pokud jsou dve moznosti pojmenovani tak uvest v clanku obe na zacatku a nadale se drzet jen jedne z nich. Takhle je to strasne matouci.
Prvni dva odstavce u "klicu" jsou tedy naprosty blabol, protoze se mluvi o indexech. Klic vam zadne nacitani nezrychli. Klic nema zadne informace ve zvlastnim souboru, respektive nikde, protoze mu na nic nejsou. Ty informace vedle ma opet index.
Jinak moznost zamenovani index/key v syntaxi je v MySQL velmi odpudiva, autori se meli rozhodnout zdali budou mit klice nebo indexy a nasledne podle toho dodrzovat syntaxi.
Na zaver bych si jenom trosku rypnul. Clovek, ktery pise do odbornych periodik (byt jen binarnich) o databazich (byt jen primitivnich) by si mel nastudovat alespon terminologii v oboru.

Souhlasím  |  Nesouhlasím  |  Odpovědět
michal  |  07. 12. 2001 09:42  | 

Mam par dotazu:

Neni neefektivni zamykat celou tabulku? Existuje nejaky mechanismus na zamykani stranek popr. jednotlivych zaznamu? Co se stane, kdyz proces ktery zamknul tabulku vyhnije pred jejim odemcenim popr. co se stane kdyz dojde k deadlocku?

Existuje moznost vytvaret clusterovane indexy a jestli ano tak s jakymi omezenimi?

Je toho hodne ale myslim, ze se jedna o dotazy k veci a bude to zajimat radu lidi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pavel Cvrcek  |  07. 12. 2001 16:02  | 

Dobry den,

serial je koncipovan pro zacatecniky a je tedy dost obecny (a navic prostor je omezeny a kazdeho zajima neco jineho). Pro podrobnejsi veci je vzdy dobre sahnout po manualu.

Mate pravdu, ze zamykani cele tabulky muze byt mnohdy neefektivni, ale tento serial je koncipovan... viz. predchazejici odstavec.  Konkretne k uzamykani. V manualu se o tom hovori v casti nazvane: G4. Locking Methods.

Currently MySQL only supports table locking for ISAM/MyISAM and HEAP tables and page level locking for BDB tables. With MyISAM tables one can freely mix  INSERT and  SELECT without locks (Versioning).

V manualu takez naleznete duvody, proc tomu tak je. Co se tyka deathlocku, tak o tom se pise zde (doufam, ze jsem Vas pochopil spravne):

All locking in MySQL is deadlock-free. This is managed by always requesting all needed locks at once at the beginning of a query and always locking the tables in the same order.

Co se tyce "vyhniteho" pripojeni. Kdyz spojeni tzv. vytuhne jeste pred opetovnem odemceni tabulky, tak je po toto spojeni po urcitem case ukonceno a tabulka automaticky odemknuta:

LOCK TABLES locks tables for the current thread. UNLOCK TABLES releases any locks held by the current thread. All tables that are locked by the current thread are automatically unlocked when the thread issues another LOCK TABLES, or when the connection to the server is closed

Clusterove indexy muzete vytvaret v tabulkach, ktere jsou ve formatu InnoDB.

Every InnoDB table has a special index called the clustered index where the data of the rows is stored. If you define a PRIMARY KEY on your table, then the index of the primary key will be the clustered index.

If you do not define a primary key for your table, InnoDB will internally generate a clustered index where the rows are ordered by the row id InnoDB assigns to the rows in such a table. The row id is a 6-byte field which monotonically increases as new rows are inserted. Thus the rows ordered by the row id will be physically in the insertion order.

Accessing a row through the clustered index is fast, because the row data will be on the same page where the index search leads us. In many databases the data is traditionally stored on a different page from the index record. If a table is large, the clustered index architecture often saves a disk i/o when compared to the traditional solution.

The records in non-clustered indexes (we also call them secondary indexes), in InnoDB contain the primary key value for the row. InnoDB uses this primary key value to search for the row from the clustered index. Note that if the primary key is long, the secondary indexes will use more space.

Preji hezky den

Autor clanku

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pavel Francírek  |  10. 12. 2001 16:26  | 

Ješte doplnění: Uzamykání na úrovni řadků mají právě výše zmíněné InnoDB. A tuším, že je mají i Geminy, ale po rozkolu mezi MySQL AB a NuSphere se o tom v manuálu už nedočtete. 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tomáš Budai  |  07. 12. 2001 09:43  | 

ALTER TABLE uzivatele ADD KEY prij_idx (prijmeni, jmeno);


Předcházející příklad je typickým dvoupoložkovým klíčem, kterým zaručíme jedinečnost každého záznamu za předpokladu, že neexistuje např. 2x Novák Petr. Vícepoložkové klíče byste však měli používat pouze v nejnutnějších případech, protože zatěžují databázi mnohem více než klíče jednopoložkové.

Timto ale jednoznacnost nezarucime. Muselo by to byt takto:
ALTER TABLE uzivatele ADD UNIQUE prij_idx (prijmeni, jmeno); 
a nebo
ALTER TABLE uzivatele ADD PRIMARY KEY prij_idx (prijmeni, jmeno);

Jen pro upresneni:

Je vyhodnejsi pouzit primarni klic, kdyz to jde (treba i dvoupolozkovy).
V pripade, ze mame v tabulce 2x KEY a pouzivame vyhledavani podle obou polozek je vyhodnejsi pouzit 1x KEY a 1x dvoupolozkovy KEY. Velikost klice se skoro nezvetsi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pavel Cvrcek  |  07. 12. 2001 15:00  | 

Dobry den,

jiste mate pravdu. Za chybu se omlouvam.

Autor clanku

Souhlasím  |  Nesouhlasím  |  Odpovědět
Martin Martinovic  |  07. 12. 2001 16:14  | 

Hledal jsem nejaky navod jak zacit s MySQL, tenhle serial je skvely. Diky za ten seznam kapitol, dal jsem si to dohromady uz vcera a takhle jsem si to zkontroloval.

Jinak koukam na prispevky a jsou tam nejaky upozorneni na chyby.

Mam navrh pro autora, jestli by mohl na konec serialu vydat Errata, tedy seznam vsech chyb (i kdyz verim, ze jich bude minimalne), abychom si to mohli opravit?

Diky,

Martin

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Pavel Cvrcek  |  07. 12. 2001 20:02  | 

Abych rekl pravdu, tak uz jsem nad necim takovym jiz uvazoval. Netvrdim sice ze to bude hned, ale rad bych neco takoveho sepsal. Bohuzel to nejspis nebude zverejneno na Zive, ale nekde mimo. Odkaz bych pak zverejnil v diskuzi u posledniho clanku, popripadne mi zajemci mohou zaslat emailovou adresu a ja je pak na toto upozornim.

Autor

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Kuznik  |  10. 12. 2001 21:26  | 

Zkusil jsem jen tak pokusne preklopit jednu aplikaci vyuzivajici ODBC Microsoft Access driver na MySql. Dopadlo to dost tragicky. MySql ODBC nepodporuje blokove prenosy, takze plneni tabulek po jedne polozce zabralo radove vetsi cas. Databaze je sice o polovinu mensi, jenze ne moc efektivni.  Jeden slozity SQL (vraci obsah tri provazanych tabulek), ktery Access zvladl behem desitky vterin kupodivu i bez indexu, zablokoval server na mnoho hodin. Server "mysql_nt" navic pokracuje v marne praci i po odstreleni klienta. Kdybych mu nenastavil nizkou prioritu coby uzivatel SYSTEM, coz myslim neni zrovna nejjednodussi administrativni zasah, mohl jsem rovnou restartovat pocitac. Takze ukazkovy deadlock typu "denial of service".

Je to amaterske dilo za ktere bych rozhodne nedoporucoval zaplatit 200 $.

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tomáš Budai  |  11. 12. 2001 11:04  | 

Tak to neni chyba MySQL, ale optimalizace jeho ERA modelu a klicu. Me dotazy prec 3 tabulky o radove milionech zaznamu trvaji kolem 1s.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jiri Pallas  |  04. 06. 2006 09:31  | 

Autorovi unikla drobnost - index na male tabulce je potreba v pripade, ze je tabulka pres polozku propojovana s jinou tabulkou (a v pozdejsich verzich pokud je na polozce cizy klic)

Souhlasím  |  Nesouhlasím  |  Odpovědět
icco#  |  16. 10. 2006 15:55  | 

Snad uzamIkat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor
Aktuální číslo časopisu Computer

Megatest 20 procesorů

Srovnání 15 True Wireless sluchátek

Vyplatí se tisknout fotografie doma?

Vybíráme nejlepší základní desky