| Autor | Zpráva | ||
|---|---|---|---|
| Dusann Profil |
Ak potrebujem unique constraint pre kombináciu stĺpcov, čiže napríklad UNIQUE KEY (col1, col2), znamená to že pri každom inserte musí prebehnúť full scan pre kontrolu hodnôt col2 ?
|
||
| juriad Profil |
Více sloupcový index si můžeš představit jako sloučení hodnot sloupců s nějakým oddělovačem. K žádnému fullscanu nedojde.
Tedy tabulka se sloupci A a B se vůči indexu bude tvářit jako by měla jediný sloupec AB, jehož hodnoty jsou oddělené nějakým oddělovačem, který se v datech nesmí vyskytnout (pro zdejší příklad čísel jsem použil pomlčku): 1-1 1-2 1-3 1-4 1-5 # 2. pokus 2-1 # 4. pokus 2-4 # 3. pokus 2-5 3-2 # 1. pokus (někam do prostřed) 3-4 3-5 4-1 4-2 4-5 4-7 Pak vložení (2,3) bude to samé jako bys vkládal 2-3. Hledání jsem naznačil; mezi posledními dvěma pokusy není žádný záznam, takže UNIQUE nebude porušený.
Obecně vícesloupcový index funguje jako index pro jeho několik prvních sloupců. (X, Y, Z) je index zároveň pro kombinace (X), (X, Y) a (X, Y, Z). Je to vidět z toho uložení s oddělovači. Naopak není indexem pro (Y), či (X, Z). |
||
| Dusann Profil |
juriad:
> Více sloupcový index si můžeš představit jako sloučení hodnot sloupců s nějakým oddělovačem. K žádnému fullscanu nedojde. > Tedy tabulka se sloupci A a B se vůči indexu bude tvářit jako by měla jediný sloupec AB, jehož hodnoty jsou oddělené nějakým oddělovačem, který se v datech nesmí vyskytnout (pro zdejší příklad čísel jsem použil pomlčku): InnoDB fyzicky ukladá varchar hodnoty viacerých stĺpcov ako jeden string bez oddelovačov. Takže potom nerozumiem, podľa čoho sa rozlišuje ak vyberám hodnoty iba jedného zo stĺpcov. |
||
| Kajman Profil |
#4 · Zasláno: 14. 11. 2014, 17:58:06
Indexy se ukládají v jiném formátu než data řádku.
|
||
| Dusann Profil |
Dusann:
„InnoDB fyzicky ukladá varchar hodnoty viacerých stĺpcov ako jeden string bez oddelovačov. Takže potom nerozumiem, podľa čoho sa rozlišuje ak vyberám hodnoty iba jedného zo stĺpcov.“ Tak už som našiel o tom info, rozlišuje sa to na základe byte offsetov ktoré su zadefinované na začiatku každého row: http://dev.mysql.com/doc/internals/en/innodb-field-contents.html http://dev.mysql.com/doc/internals/en/innodb-overview.html |
||
| Dusann Profil |
ADMIN: Inak moja pôvodná otázka v tejto téme je chybná len som si to uvedomil neskôr - je jasné že k žiadnemu full scanu pri inserte nedôjde, keďže pri composite unique ide o kombináciu hodnôt, čiže hodnota col2 sa hľadá iba v rozsahu kde col1 spĺňa podmienku.
Poprosím teda o zmazanie témy keďže iba zbytočne mätie ostatných, dík |
||
| juriad Profil |
#7 · Zasláno: 15. 11. 2014, 01:46:46
Dusann:
S tím oddělovačem to byla jen ukázka - samozřejmě, že databáze to mají vyřešené chyřeji. SQL pouze definuje, jak se dotazy chovají vůči indexům, nikoli jak jsou indexy implementované (různé databáze různě). Nemusí tedy být pravda, že se hledá napřed podle prvního sloupce, jehož výsledek je rozsah hodnot druhého sloupce, a v něm pak zvlášť. To je plně v kompetenci databáze a tebe jako jejího uživatele by to nemělo zajímat, dokud neprokážeš, že je to místo, kde aplikace tráví podstatnou část času. Můžeš si klidně vymyslet nějaké své chytré indexy. Třeba v případě, že se index používá jen pro nalezení shody dlouhých textů, mohl by se obsah sloupců zahashovat a porovnávat hashe. V případě shody hashe se ještě zkontroluje skutečný obsah. Teoreticky bys mohl mít index počtů slov v řetězcích - pokud bys podle toho chtěl často vyhledávat. Nebo víš-li, že téměř každá kombinace hodnot bude v databázi, můžeš navrhnout inverzní index - seznam neexistujících kombinací hodnot. Smazání vlákna není nutné. Nepomůže-li nikomu dalšímu, prostě zapadne v historii. |
||
|
Časová prodleva: 9 let
|
|||
0