[MYSQL] Wat gebeurt er als er teveel records verwijderd zijn

[Verwijderd]

Hey ik vraag me af wat zijn de gevolgen als er gaten in je db komen dus daar bedoel ik mee bijv de nummering gaat van 1 tot 1000 dat er om de zoveel records 5 records missen (omdat je die verwijderd hebt) kan het op een gegeven moment langzamer gaan oid? of zelfs overbelast raken omdat hij steeds die gaten pver moet slaan en daardoor misschien langzamer gaat?..

thx voor het antwoordne vroeg ik me gewoon af

[D2k]

nix volgens mij

[drm]

Euh

Laat ik een paar wedervragen stellen:

• Je bedoelt dat de autonummering niet meer van 'ene, tweeje, drieje' gaat, maar van 'ene, zesse, negene', ofzo?
• Waarom heb je het vermoeden dat dat wat uitmaakt? Waar baseer je dat op?
• En wat bedoel je met "overslaan"?
• Waarom denk je dat er "gaten" vallen?
• Waar zouden die "gaten" dan moeten zitten? Op de harde schijf

Als je die allemaal beantwoord hebt, zal je je eigen vraag ook wel zo ongeveer beantwoord hebben.

[Verwijderd]

drm schreef op 28 November 2002 @ 09:22:
Euh

Laat ik een paar wedervragen stellen:
[list]• Je bedoelt dat de autonummering niet meer van 'ene, tweeje, drieje' gaat, maar van 'ene, zesse, negene', ofzo?

Ja dit bedoel ik ja

• Waarom heb je het vermoeden dat dat wat uitmaakt? Waar baseer je dat op?

Nou kijk als het autonummering is en hij vraagt de tabel aan dan leest hij alles in (tenzij je de waarde van de tabel (de rows geeft) en als hij dan niet het nr kan vinden?

• En wat bedoel je met "overslaan"?

Nou kijk.. als hij bijv eerst begint bij: 1 tot 10 000 en dat bijv record 300 tot 600 en 4000 tot 4500 leeg is bijv omdat je die records hebt verwijderd

• Waarom denk je dat er "gaten" vallen?

Records (rows) die nietmeer in de tabel staan (dus de inhoud) en dus ook de nummering.

• Waar zouden die "gaten" dan moeten zitten? Op de harde schijf

Ik bedoel met gaten lege records die niet meer bestaan (omdat als je record 1 tot 10 hebt) en je verwijderd 5 dan slaat hij 5 over

[Verwijderd]

Nou dat maakt volgens mij echt niet uit voor de snelheid hoor. In ieder geval nog nooit van gehoord dat dat zou kunnen

[thomaske]

hij slaat helemaal niets over, het auto-nummer veld is gewoon een nummer, om een veld te identificeren. Verder niets!!

Er zijn dus geen 'gaten' en al helemaal geen 'lege records'!

[Peetman]

Dat is nou juist het leuke van een database, daar hoor je geen last van te hebben ivm een goede indexering enzo

[drm]

Mja, maar als een record er "niet meer is" waarom zou hij 'm dan overslaan? Ik bedoel: je kan niets overslaan wat er niet is.

Voorbeeldje: er staat een stel kinderen voor je. Die ga je tellen. Je begint bij de eerst en stopt bij de laatste. In totaal tel je 20 kinderen.

Vervolgens worden er 7 kinderen opgehaald. Je telt de kinderen opnieuw. Je telt er 13. Maakt het dan uit dan die kinderen die weggegaan zijn niet meer in de rij staan? Ja, alleen in het totaal, maar het feit dat hun plekjes nu leeg zijn, dat maakt toch niet uit?

[whoami]

Het heeft geen invloed op de performance of wat dan ook van de databank.
Check ook dit topic:
[rml][ MySQL] auto increment terugzetten[/rml]/
Vooral vanaf hier dan: [rml]whoami in "[ MySQL] auto increment terugzetten"[/rml]

[ Voor 20% gewijzigd door whoami op 28-11-2002 09:47 ]

[ACM]

peetman schreef op 28 November 2002 @ 09:32:
Dat is nou juist het leuke van een database, daar hoor je geen last van te hebben ivm een goede indexering enzo

Dat heeft helemaal niks met indexering te maken

Want dan impliceer je dat het _wel_ uitmaakt als je geen indexering hebt en dat is onzin.
Het is gewoon zo:
1
2
3
4
5
6 >- wordt verwijderd
7
8
9

1
2
3
4
5 >- begin "gat"
7 >- eind "gat"
8
9

En het is net zo makkelijk allemaal op rij uit te lezen als wanneer dat getal er wel geweest zou zijn.
Het zou wel erg bijzonder zijn als dat _wel_ uitmaakte, er wordt namelijk niet een verzameling gemaakt met alle mogelijke id's (dat moet tenslotte van -2 miljard en +2 miljard lopen dan, als je het helemaal goed wil doen), maar met alle gebruikte id's.

[Bosmonster]

Zie het zo:

Zouden er gaten vallen als je geen auto-nummering gebruikte, maar bijvoorbeeld een varchar primary key?

Precies.. de PK is slechts een unieke identifier voor de row en of de nummers nu achterstevoren lopen of compleet random met 'gaten' van hier tot tokyo maakt niks uit.

[ACM]

Bosmonster schreef op 28 November 2002 @ 10:04:
of compleet random met 'gaten' van hier tot tokyo maakt niks uit.

Nou, dat wel hoor
Als het begin van het gat hier staat en het eind van het gat in Tokyo, dan zal het er significant slomer van worden als je alles in gaat lezen

[Annie]

peetman schreef op 28 november 2002 @ 09:32:
Dat is nou juist het leuke van een database, daar hoor je geen last van te hebben ivm een goede indexering enzo

Ik weet niet hoe het exact werkt in mysql, maar in bijvoorbeeld mssql maakt het afaik wel uit of er "gaten" in de data/index zitten. Of je er iets van merkt is een tweede, maar data wordt verdeeld over pages en bij een lage fill factor (grote gaten) moet er om dezelfde hoeveelheid records binnen te halen meer pages gelezen worden.

[whoami]

Annie schreef op 28 November 2002 @ 23:34:
[...]

Ik weet niet hoe het exact werkt in mysql, maar in bijvoorbeeld mssql maakt het afaik wel uit of er "gaten" in de data/index zitten. Of je er iets van merkt is een tweede, maar data wordt verdeeld over pages en bij een lage fill factor (grote gaten) moet er om dezelfde hoeveelheid records binnen te halen meer pages gelezen worden.

En kan je dat niet 'herstellen' oid?

[ACM]

Annie schreef op 28 November 2002 @ 23:34:
Ik weet niet hoe het exact werkt in mysql, maar in bijvoorbeeld mssql maakt het afaik wel uit of er "gaten" in de data/index zitten. Of je er iets van merkt is een tweede, maar data wordt verdeeld over pages en bij een lage fill factor (grote gaten) moet er om dezelfde hoeveelheid records binnen te halen meer pages gelezen worden.

Dat is idd iets dat bij Postgresql significant aan de orde kan zijn, vandaar ook het dagelijks gebruik van de 'vacuum' (niet verplicht, wel aangeraden) en gelukkig proberen ze dat te verhelpen in de volgende versie (7.4 of 8.0 geloof ik).

In mysql gebeurt dat deels automatisch geloof ik en verder is er het 'optimise table'.

[ Voor 7% gewijzigd door ACM op 29-11-2002 10:23 ]

[Verwijderd]

een database is een verzameling data. als er hier en daar GEEN data is (wat jij noemt een gat), dan staat die data dus ook NIET in de DB. hoe kan je ergens last van hebben wat niet bestaat? dus qua opslag maakt het niet uit.

qua snelheid van opzoeken maakt het wel ietsie pietsie uit
een db indexeert bep kolommen, (niet helemaal, maar even voor de uitleg) netzoals een telefoonboek.
als er in een telefoon boek heel veel mensen met "jansen" dan is de index pagina met "jan" langer dan die van "xie" (want er bestaan haast geen mensen met een achternaam als "xieman"). logisch dat het zoeken naar een bepaald iemand in de index "jan" wat langer duurt dan iemand in de index "xie". eenvoudig genoeg omdat de index "jan" gewoon meer gegevens bevat (en dus iets langer duurt om door te nemen). maar daarentegen is het resultaat naar een zoekopdracht met "xieman" heel snel gevonden (weinig gegevens).
gemiddeld gezien, heb je met een "scheve" index dus geen last, de ene is sneller dan andere langzamer, gemiddeld dus normaal.

[Annie]

whoami schreef op 29 November 2002 @ 09:14:

[...]


En kan je dat niet 'herstellen' oid?

Natuurlijk kan dat, maar de vraag is of je dat altijd wil. Bij een fill-factor van 100% op je index en een table waarin geschreven wordt zal altijd een page split moeten plaatsvinden en dat kost dus performance. Een te lage fill-factor geeft weinig page splits maar weer meer overhead bij het ophalen van gegevens en bovendien heb je meer schijfruimte nodig.
Normaalgesproken is dit absoluut geen issue natuurlijk. De default instellingen voldoen prima. En op het moment dat het wel interessant wordt heb je meestal ook wel een duurbetaalde dba rondlopen die dat allemaal voor je optimaliseert .

offtopic:
(disclaimer: ik ben geen expert, dus be gentle als ik een foutje maak)

[ACM]

Verwijderd schreef op 29 November 2002 @ 11:24:
gemiddeld gezien, heb je met een "scheve" index dus geen last, de ene is sneller dan andere langzamer, gemiddeld dus normaal.

Euh...
Jouw verhaal heeft alleen erg weinig met die gaten te maken, die gaten veroorzaken eerder een betere dan een slechtere spreiding, maar statistisch gezien zal de spreiding vast niet al te veel afnemen (niets waarschijnlijk)...

[ Voor 3% gewijzigd door ACM op 29-11-2002 20:21 ]

[Kaastosti]

Ik heb een dergelijke vraag gesteld paar daagjes terug.. maar dan meer met betrekking tot de auto-nummering. Die ging als ik van 1-10 nummer 5-10 weghaalde wel gewoon vrolijk verder bij 11. Ik wilde dit fixxen met een soort her-index scriptje, maar dat werd mij door iedereen afgeraden. Die gaten gebeurd toch verder niets mee en zullen dus ook geen problemen opleveren. Het zal hooguit een paar milliseconden schelen... maar ach

[ACM]

Kaastosti schreef op 29 november 2002 @ 20:25:
Het zal hooguit een paar milliseconden schelen... maar ach

Nou, dat zou nog vrij veel zijn

Ik schat dat het bij de meeste queries niets kost (de gaten zelf dan, eventueel wel dat de "lege records die er nog zijn" wel wat performance kosten, maar of je dat echt merkt?)

[_Thanatos_]

Ik denk dat je je sowieso niet bezig moet houden met de werking van de sql server. een sql server is juist gemaakt om het werk te doen zodat jij alleen nog maar de juiste queries hoeft te verzinnen. Een sql server is meestal ook zo ontworpen dat ie zo efficient mogelijk met je data omgaat.

Dus als het trager wordt, moet je denk ik eerder naar je indices/queries kijken, of zelfs naar je server wijzen, dan gaan kijken waarom mysql dingen trager afhandelt.