Ik heb ooit met een zeer grote (Terabyte+) MySQL-database gewerkt. De grootste tafel die we hadden was letterlijk meer dan een miljard rijen.
Het werkte. MySQL heeft de gegevens meestal correct verwerkt. Het was wel erg onhandig.
Alleen het maken van een back-up en het opslaan van de gegevens was een uitdaging. Het zou dagen duren om de tafel te herstellen als dat nodig was.
We hadden talloze tafels in het bereik van 10-100 miljoen rijen. Alle belangrijke joins aan de tafels waren te tijdrovend en zou een eeuwigheid duren. Dus schreven we opgeslagen procedures om de tabellen te 'lopen' en joins te verwerken tegen reeksen van 'id's. Op deze manier zouden we de gegevens 10-100.000 rijen per keer verwerken (deelnemen tegen id's 1.000.000 dan 100.001-200.000, enz.). Dit was aanzienlijk sneller dan meedoen tegen de hele tafel.
Het gebruik van indexen op zeer grote tabellen die niet op de primaire sleutel zijn gebaseerd, is ook veel moeilijker. Mysql slaat indexen in twee delen op -- het slaat indexen (anders dan de primaire index) op als indexen voor de primaire sleutelwaarden. Dus geïndexeerde zoekopdrachten worden in twee delen gedaan:eerst gaat MySQL naar een index en haalt daaruit de primaire sleutelwaarden die het moet vinden, dan doet het een tweede zoekopdracht op de primaire sleutelindex om te vinden waar die waarden zijn.
Het nettoresultaat hiervan is dat voor zeer grote tabellen (1-200 miljoen plus rijen) indexering tegen tabellen restrictiever is. U hebt minder, eenvoudigere indexen nodig. En zelfs simpele select-statements die niet direct op een index staan, komen misschien nooit meer terug. Waar clausules moeten hit indexen of vergeet het.
Maar dat gezegd hebbende, de dingen werkten echt. We konden MySQL gebruiken met deze zeer grote tabellen en berekeningen uitvoeren en antwoorden krijgen die correct waren.