MySQL en InnoDB

Interessant stukje. Bedankt.

Supertutorial. Ik heb voor het eerst niet eens commentaar :)

(Y) toppie tut, zal nog even duren voordat ik het ga gebruiken, maar ik weet dat het bestaat op deze site...

Keep on going!!!

Goeie tut!

Die link die aan het eind staat is ook wel interessant!

Dit kan ik zeker gebruiken vooral "Wat zijn PK / FK-relaties".

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...

Met zulk soort databases zou ik nieteens willen denken aan MySQL...hoe ga je in hemelsnaam zoveel data consistent houden?

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 ;-)

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????

Wel jammer dat InnoDB geen fulltext aankan ;)

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 ?

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.

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...

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!

Yes, mijn FK's zijn gelukt :) Dankjewel! Heldere tutorial! Kort maar krachtig.

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?