Je zult zeker problemen krijgen met die 42 GB-tafel als deze niet meer in het geheugen past. Sterker nog, zodra het niet meer in het geheugen past, gaan de prestaties extreem snel achteruit. Een manier om te testen is om die tafel op een andere machine met minder RAM te zetten en te kijken hoe slecht hij presteert.
Dit is incorrect. Partitionering (ofwel via de functie in MySQL 5.1, of hetzelfde met behulp van MERGE-tabellen) kan aanzienlijke prestatievoordelen opleveren, zelfs als de tabellen zich op dezelfde schijf bevinden.
Laten we als voorbeeld stellen dat u SELECT-query's uitvoert op uw grote tafel met een datumbereik. Als de tabel heel is, wordt de query gedwongen door de hele tabel te scannen (en bij die grootte kan zelfs het gebruik van indexen traag zijn). Het voordeel van partitionering is dat uw query's alleen worden uitgevoerd op de partities waar dit absoluut noodzakelijk is. Als elke partitie 1 GB groot is en je query slechts toegang nodig heeft tot 5 partities om zichzelf te vervullen, is de gecombineerde 5 GB-tabel een stuk gemakkelijker voor MySQL om mee om te gaan dan een monsterlijke 42 GB-versie.
Een ding dat u zich moet afvragen, is hoe u de gegevens opvraagt. Als de kans bestaat dat uw zoekopdrachten alleen toegang nodig hebben tot bepaalde hoeveelheden gegevens (d.w.z. een datumbereik of ID-bereik), zal het op een of andere manier nuttig zijn om te partitioneren.
Ik heb gehoord dat er nog steeds wat bugs zijn met MySQL 5.1-partitionering, met name gerelateerd aan het kiezen van de juiste sleutel door MySQL. MERGE-tabellen kunnen dezelfde functionaliteit bieden, hoewel ze iets meer overhead vereisen.
Ik hoop dat dat helpt ... veel succes!