MySQL en InnoDB

Door Remco van Arkelen, 22 jaar geleden, 10.450x bekeken

Hoe MySQL ondersteuning voor transactions en referentiële integriteit biedt.

Gesponsorde koppelingen

Inhoudsopgave

  1. Inleiding
  2. Wat zijn transactions?
  3. Wat zijn PK / FK-relaties
  4. Het leuke werk, integriteit behouden
  5. Een stukje voorbeeldcode
  6. Tips & Tricks

 

Er zijn 16 reacties op 'Mysql en innodb'

PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
- SanThe -
- SanThe -
22 jaar geleden
 
0 +1 -0 -1
Interessant stukje. Bedankt.
PHP erik
PHP erik
22 jaar geleden
 
0 +1 -0 -1
Supertutorial. Ik heb voor het eerst niet eens commentaar :)
Marien xD
Marien xD
22 jaar geleden
 
0 +1 -0 -1
(Y) toppie tut, zal nog even duren voordat ik het ga gebruiken, maar ik weet dat het bestaat op deze site...

Keep on going!!!
Onbekend onbekend
onbekend onbekend
22 jaar geleden
 
0 +1 -0 -1
Goeie tut!

Die link die aan het eind staat is ook wel interessant!
Steff   an
Steff an
22 jaar geleden
 
0 +1 -0 -1
Dit kan ik zeker gebruiken vooral "Wat zijn PK / FK-relaties".
Willem vp
Willem vp
22 jaar geleden
 
0 +1 -0 -1
Wanneer performance van je database belangrijk gaat worden, kun je overigens beter overwegen MyISAM te gebruiken. Op een tabel van 480 miljoen records is InnoDB niet vooruit te branden (simpele queries als "select * from db limit 420835721,30" doen er rustig zo'n 12 uur over) terwijl MyISAM nog wel enigszins acceptabel performt (dezelfde query doet er zo'n 5 minuten over).

Ook het diskgebruik van InnoDB is niet leuk (39 GB t.o.v. 'slechts' 17 GB voor een MyISAM-tabel).

Okay, een database van 480 miljoen records is ook niet ideaal, maar dat is nu juist hetgene wat ik moet zien te optimaliseren ;-) en ik heb al gemerkt dat ik dat heel graag wil doen zonder InnoDB...
Remco van Arkelen
Remco van Arkelen
22 jaar geleden
 
0 +1 -0 -1
Met zulk soort databases zou ik nieteens willen denken aan MySQL...hoe ga je in hemelsnaam zoveel data consistent houden?
Willem vp
Willem vp
22 jaar geleden
 
0 +1 -0 -1
Gelukkig betreft het meetgegevens die -wanneer ze eenmaal zijn geregistreerd- niet meer gewijzigd hoeven te worden. Ik hoef me dus gelukkig niet druk te maken over integrity constraints etc. Wel wacht me de schone taak om statistische analyse uit te voeren, zodat we daarna realtime verwachtingen kunnen berekenen.

En tsja, een jaar of vijf geleden heeft iemand de keuze gemaakt voor MySQL en daar zijn intussen zoveel PHP/Perl scripts omheen geschreven dat het teveel moeite kost om over te gaan op iets anders. Ik zit nu zelfs al met het dilemma of op onze nieuwe server MySQL 4.1 moet blijven draaien, of dat we overgaan op MySQL 5, die een heleboel features biedt waar ik behoefte aan heb (views bijvoorbeeld) maar die nog wel steeds in het beta-stadium is...

Aan de andere kant... als ik op de huidige database ga zitten queryen raakt de CPU dusdanig overbelast dat ik een kwartier aan meetgegevens kwijtraak. Volgens mij kunnen we er met versie 5 alleen maar op vooruit gaan ;-)
Martijn B
Martijn B
22 jaar geleden
 
0 +1 -0 -1
Als je een tabel hebt waar veel in veranderd denk dus aan UPDATE en INSERT queries, dan kun je altijd het beste InnoDB gebruiken. Omdat InnoDB row level locking ondersteund.

Dus verander ik iets in een tabel dan kunnen andere queries dat record(s) niet veranderen. Met MyISAM kunnen andere queries de hele tabel dan niet veranderen omdat deze tabel level locking ondersteund. Volgens mij scheeld dit enorm in de uitvoer tijden.

Willem vp:
Als je een tabel hebt met 480 Miljoen records moet je er vast in kunnen zoeken, en dan kom je toch uit op MyISAM ;D...


Had je trouwens wel goede indexes????


22 jaar geleden
 
0 +1 -0 -1
Wel jammer dat InnoDB geen fulltext aankan ;)
Pim Vernooij
Pim Vernooij
22 jaar geleden
 
0 +1 -0 -1
Quote:
Wat kun je nou met die relaties? Nou, je dwingt op database-niveau af dat er in de tabel met berichten alleen records kunnen zitten van gebruikers welke voorkomen in de tabel met gebruikers!
Wat gebeurt er als er berichten van een gebruiker in de tabel staan, maar dat de gebruiker iets later verwijdert word? of word er alleen bij het invoeren gecontroleerd of het userId bestaat ?
Remco van Arkelen
Remco van Arkelen
22 jaar geleden
 
0 +1 -0 -1
Dat kun je vastleggen in je constraint. Je kunt bijvoorbeeld zeggen

ALTER TABLE berichten ADD FOREIGN KEY(gebruiker_id) REFERENCES gebruiker(id) ON DELETE RESTRICT

Als er dan een gebruiker wordt weggegooid zal dit door de database worden geweigerd als er nog berichten van deze gebruiker in de tabel berichten staan.

Als je nu wilt dat de berichten ook worden verwijderd kun je dit zo doen:

ALTER TABLE berichten ADD FOREIGN KEY(gebruiker_id) REFERENCES gebruiker(id) ON DELETE CASCADE.
Rudie dirkx
rudie dirkx
21 jaar geleden
 
0 +1 -0 -1
Quote:
Een PK is de sleutel tot 1 record in een tabel, ieder record in je tabel(len) hoort een eigen PK te hebben, in MySQL realiseer je dit met een INTEGER welke je AUTO_INCREMENT maakt, zo dwingt MySQL min of meer af dat je altijd een unieke waarde hebt, het vreemde is dan weer als je een tabel leegt dat de PK ook weer opnieuw begint. Iets wat eigenlijk niet hoort.

Dat is dan ook niet waar. Als je een InnoDB tabel TRUNCATE blijft de AUTO_INCREMENT value staan op waar ie was. En al werd ie op 1 gezet... Dat zou niet uit moeten maken, want ALLE relaties zijn weg als een tabel leeg is gegooid! Of je hebt een slecht InnoDB datamodel gemaakt...
Remco van Arkelen
Remco van Arkelen
21 jaar geleden
 
0 +1 -0 -1
Quote:
Dat is dan ook niet waar. Als je een InnoDB tabel TRUNCATE blijft de AUTO_INCREMENT value staan op waar ie was.


Dat is toch niet helemaal het geval, ik heb het zojuist getest op MySQL versie 5.0.24 en 5.0.18. De auto-increment begint gewoon weer bij 1 na het uitvoeren van een TRUNCATE op een InnoDB-tabel. Op welke versie heb jij het getest, dan kan ik dat erbij vermelden.

Met je andere punt ben ik het grotendeels wel eens, anderzijds kan het voorkomen dat je nog geen relaties hebt in het datamodel (het artikel is immers bedoelt voor mensen die hier nog geen weet van hebben), om aan te geven dat MySQL niet/weinig doet om haar data consistent te houden.

Bedankt voor je reactie!
- -
- -
20 jaar geleden
 
0 +1 -0 -1
Yes, mijn FK's zijn gelukt :) Dankjewel! Heldere tutorial! Kort maar krachtig.
PHP hulp
PHP hulp
0 seconden vanaf nu
 

Gesponsorde koppelingen
Mark Eilander
Mark Eilander
16 jaar geleden
 
0 +1 -0 -1
Hoe werken ON DELETE CASCADE en transacties samen?
Kan ik EN het voordeel van transacties gebruiken EN het voordeel van ON DELETE CASCADE gezamelijk gebruiken?

Om te reageren heb je een account nodig en je moet ingelogd zijn.

Inhoudsopgave

  1. Inleiding
  2. Wat zijn transactions?
  3. Wat zijn PK / FK-relaties
  4. Het leuke werk, integriteit behouden
  5. Een stukje voorbeeldcode
  6. Tips & Tricks

Labels

  • Geen tags toegevoegd.

PHP tutorial opties

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.