[mysql] Primaire sleutel ook index?

[Verwijderd]

Is het verstanding om op de primaire sleutel van een tabel ook een index te plaatsen ivm snelheid? Of is dit automatisch al een index? Wie kan me hier wat over vertellen? Thanks already.

[whoami]

Een primary key is al een unique index.

[Verwijderd]

niks mee doen dus. Ik kan er zo namelijk nog een index overheen gooien, maar dat dus onnodig zijn? Iemand ervaring met performance?

[ACM]

Een primaire sleutel is niet perse een index overigens, maar in mysql wordt dat wel door een unique index aan te leggen gedaan. En ik ken geen enkele database die dat niet zo doet, maar zoveel van de interne werking van de meeste db's weet ik niet

Voor performance kan het wel handig zijn een gecombineerde index aan te leggen waar je primaire sleutel deel van kan uitmaken.

[OZ-Gump]

Voor zover ik weet is de primary key altijd een index.

[ Voor 35% gewijzigd door OZ-Gump op 10-06-2003 11:49 ]

[Glimi]

quote: http://www.mysql.com/doc/en/CREATE_TABLE.html

A PRIMARY KEY is a unique KEY where all key columns must be defined as NOT NULL. If they are not explicitly declared as NOT NULL, it will be done implicitly (and quietly). In MySQL the key is named PRIMARY. A table can have only one PRIMARY KEY. If you don't have a PRIMARY KEY and some applications ask for the PRIMARY KEY in your tables, MySQL will return the first UNIQUE key, which doesn't have any NULL columns, as the PRIMARY KEY.

Staat dus letterlijk in de manual, gelieve die er eerst op na te slaan voordat je in P&W een topic opent

http://www.mysql.com/doc/en/MySQL_indexes.html is ook wel handig trouwens om te lezen

[ Voor 8% gewijzigd door Glimi op 10-06-2003 11:54 ]

[whoami]

ACM schreef op 10 juni 2003 @ 11:48:
Voor performance kan het wel handig zijn een gecombineerde index aan te leggen waar je primaire sleutel deel van kan uitmaken.

Als je een gecombineerde index aanmaakt waarvan de PK deel uitmaakt, kan het idd handig zijn (als je veel zoek op de combinatie van die velden dus), maar ik vraag me af wat het nut ervan is....

Als je echter een index legt op slechts dat ene veld, dan zal het de performance niet ten goede komen; Als je inserts/updates/deletes doet, dan moeten de indexen op de tabel bijgewerkt worden. Hoe meer indexen je hebt, hoe meer hij er dus moet bijwerken. Aangezien je dan gewoon dubbele indexen hebt, creeër je gewoon tijdverlies.

Trouwens, filteren op PK is de snelste manier om een record op te halen.

[Creepy]

Glimi schreef op 10 June 2003 @ 11:52:
[...]

Staat dus letterlijk in de manual, gelieve die er eerst op na te slaan voordat je in P&W een topic opent

http://www.mysql.com/doc/en/MySQL_indexes.html is ook wel handig trouwens om te lezen

* Creepy leest daar nergens dat de primary key ook automatisch een index heeft?

[ Voor 3% gewijzigd door Creepy op 10-06-2003 12:10 ]

[Creepy]

whoami schreef op 10 June 2003 @ 11:54:
[...]

Als je echter een index legt op slechts dat ene veld, dan zal het de performance niet ten goede komen; Als je inserts/updates/deletes doet, dan moeten de indexen op de tabel bijgewerkt worden. Hoe meer indexen je hebt, hoe meer hij er dus moet bijwerken. Aangezien je dan gewoon dubbele indexen hebt, creeër je gewoon tijdverlies.

Maar de tijdwinst bij het selecteren kan enorm zijn

[whoami]

Creepy schreef op 10 June 2003 @ 12:11:
[...]

Maar de tijdwinst bij het selecteren kan enorm zijn

Inderdaad, maar als je 2 indexen op hetzelfde veld legt (en het zijn geen gecombineerde indexen), dan is het gewoon tijdverlies.
Het maakt niet uit of je nu 1, 2 of 3x dezelfde index op een bepaald veld legt.

[ACM]

whoami schreef op 10 June 2003 @ 11:54:
Trouwens, filteren op PK is de snelste manier om een record op te halen.

Dat hoeft helemaal niet zo te zijn

Vooral niet als je op een foreign key aan het zoeken bent, dan wil je geen primary key aflopen en dan kijken of de foreign key wel matched

Creepy schreef op 10 June 2003 @ 12:09:
* Creepy leest daar nergens dat de primary key ook automatisch een index heeft?

Bij MySQL heet een 'index' ook een 'key'

whoami schreef op 10 June 2003 @ 12:13:
Het maakt niet uit of je nu 1, 2 of 3x dezelfde index op een bepaald veld legt.

Als ik op hetzelfde veld twee verschillende indices (een btree, een bitmap, ...) aanleg kan het nog wel uitmaken voor de verschillende operaties (bitmap/hash voor de = operator, btree voor ranges, etc), maar in principe heb je gelijk ja

[whoami]

ACM schreef op 10 juni 2003 @ 12:17:
[...]

Dat hoeft helemaal niet zo te zijn

Vooral niet als je op een foreign key aan het zoeken bent, dan wil je geen primary key aflopen en dan kijken of de foreign key wel matched

Ja Duh.

[Verwijderd]

Ik ben blij dat dit topic weer geopend was. Hij was inderdaad te vroeg gesloten en had ik nog geen antwoord op mijn vraag. Ik had de manual al gelezen en kon daar niks vinden over PK EN index. Dus vandaar.... Inmiddels is het duidelijk. Hartelijk dank.

[Verwijderd]

Dat hoeft helemaal niet zo te zijn

Vooral niet als je op een foreign key aan het zoeken bent, dan wil je geen primary key aflopen en dan kijken of de foreign key wel matched

De primairy key komt in het bovenstaande geval toch al niet in de select voor, de index op die kolom wordt dan toch ook niet gebruikt is t wel ?

[ACM]

Je kan best voorbeelden bedenken waarbij er een selectclause op zowel de primairy key als een of meerdere foreign keys wordt uitgevoerd

Bijvoorbeeld het werken met pagina's in een forum waar je geen "offset Y" kan gebruiken, dan zou je de "laatst getoonde" primary-key van een reactie kunnen gebruiken ala:
select top X from a where a.foreignid = Z and a.primid > Y

In dit geval zal een gecombineerde index op de foreignid + primid het beste zijn, maar ondanks dat moet ie in zo'n geval waarschijnlijk _niet_ de primkey doorzoeken maar de index op de foreign key (tenzij die er niet is enzo )

[Creepy]

ACM schreef op 10 June 2003 @ 12:17:
Bij MySQL heet een 'index' ook een 'key'

Ah, dat scheelt

[Glimi]

Verwijderd schreef op 10 June 2003 @ 12:50:
Ik ben blij dat dit topic weer geopend was. Hij was inderdaad te vroeg gesloten en had ik nog geen antwoord op mijn vraag. Ik had de manual al gelezen en kon daar niks vinden over PK EN index. Dus vandaar.... Inmiddels is het duidelijk. Hartelijk dank.

Dan heb je niet op de links geklikt welke ik in mijn post gegeven had. De reden dat ik het topic ook heropend heb, was dat er ondertussen een redelijke discussie op gang kwam. Niet jouw inzet

[Verwijderd]

Eh.. imo heeft een gecombineerde index waar de PK in zit nooit zin. Tenzij je PK niet unique is, en dat wil je niet.

Waarom zeg ik dit? Een index gebruik je als je een bepaald gegeven weet. De gegevenset is dan gesorteerd op basis van dat gegeven.

Zodra je de PK weet, heb je geen andere velden meer nodig. Immers de PK is een unieke en altijd voorkomende waarde voor een record. Met de PK kun je maar 1 record selecteren, niet meerdere.

Een gecombineerde sleutel waar de primaire sleutel deel van uitmaakt heeft dan ook nooit zijn imo.

[ Voor 6% gewijzigd door Verwijderd op 10-06-2003 16:07 ]

[whoami]

Verwijderd schreef op 10 June 2003 @ 16:06:
Eh.. imo heeft een gecombineerde index waar de PK in zit nooit zin.

Idd. Dat heb ik ook al in één van m'n eerdere posts willen verwoorden, maar blijkbaar is dat niet zo goed gelukt.

Tenzij je PK niet unique is, en dat wil je niet.

Zowiezo kan je -AFAIK- een veld slechts als PK definieren als dat veld uniek is.

Zodra je de PK weet, heb je geen andere velden meer nodig. Immers de PK is een unieke en altijd voorkomende waarde voor een record. Met de PK kun je maar 1 record selecteren, niet meerdere.

Een gecombineerde sleutel waar de primaire sleutel deel van uitmaakt heeft dan ook nooit zijn imo.

Idd, want die gecombineerde sleutel is dan zowiezo ook altijd uniek.

[Creepy]

Glimi schreef op 10 June 2003 @ 16:03:
[...]

Dan heb je niet op de links geklikt welke ik in mijn post gegeven had. De reden dat ik het topic ook heropend heb, was dat er ondertussen een redelijke discussie op gang kwam. Niet jouw inzet

offtopic:
/me had overigens ook op de links geklikt en even snel doorgelezen jij pauper

En ergens stiekum midden in de create_table.html staat weggemoffeld:
KEY is a synonym for INDEX.

[ Voor 11% gewijzigd door Creepy op 10-06-2003 16:16 ]

[Olaf van der Spek]

Verwijderd schreef op 10 June 2003 @ 16:06:
Zodra je de PK weet, heb je geen andere velden meer nodig. Immers de PK is een unieke en altijd voorkomende waarde voor een record. Met de PK kun je maar 1 record selecteren, niet meerdere.

Dat geldt alleen voor =, niet voor < (enz).
Als je bijvoorbeeld een index (f(orum)id, pk) hebt dan kan die gebruikt worden in een query als: "select * from ... where fid = 1 and pk > 10.

[ACM]

Verwijderd schreef op 10 June 2003 @ 16:06:
Zodra je de PK weet, heb je geen andere velden meer nodig. Immers de PK is een unieke en altijd voorkomende waarde voor een record. Met de PK kun je maar 1 record selecteren, niet meerdere.

Een gecombineerde sleutel waar de primaire sleutel deel van uitmaakt heeft dan ook nooit zijn imo.

Dat geldt niet als je een lijst van PK's hebt of een stel eisen waar ie aan moet voldoen.

Mijn eerdere (en door olaf herhaalde) voorbeeld met een forum lijkt me volkomen legaal en bruikbaar voor databases die geen offset kennen.

Imho moet je heel erg oppassen met uitspraken als "heb je nooit nodig", "je kan altijd zonder". Het is vast zo dat het altijd zonder kan, maar we proberen natuurlijk zo veel mogelijk de beste en/of meest haalbare oplossing te vinden. Niet perse de "meest correcte" (in paradigma termen wel te verstaan), "de mooiste" of "de netste".

Imho heeft elke index die je niet kan verantwoorden geen bestaansrecht, maar als jij een index hebt die je perfect kan verantwoorden waar een bepaald veld (bijv een prim key) deel van uitmaakt, waarom niet?

Btw...
Een gecombineerde primary key, bij een database die indices aanlegt voor je prim.key-checks maakt per definitie dan een gecombineerde index aan voor je primary key velden, is dat ook fout?
En wat als je regelmatig zoektochten doet op een of meer van die kolommen _en_ een andere kolom?

[jochemd]

whoami schreef op 10 June 2003 @ 16:11:

Zowiezo kan je -AFAIK- een veld slechts als PK definieren als dat veld uniek is.

De waardes in het veld moeten uniek zijn. Het veld zelf hoeft niet als zijnde uniek gedefinieerd te worden, dat doet de database wel voor je op het moment dat je hem als primary key definieert. (Volgens de SQL standaard dan, bepaalde databases hebben daar enigszins moeite mee.)