Du vil helt sikkert begynde at løbe ind i problemer på det 42 GB bord, når det ikke længere passer i hukommelsen. Faktisk, så snart det ikke passer i hukommelsen længere, vil ydeevnen forringes ekstremt hurtigt. En måde at teste på er at placere den tabel på en anden maskine med mindre RAM og se, hvor dårlig den yder.
Dette er forkert. Partitionering (enten gennem funktionen i MySQL 5.1 eller det samme ved hjælp af MERGE-tabeller) kan give betydelige ydeevnefordele, selvom tabellerne er på det samme drev.
Lad os som et eksempel sige, at du kører SELECT-forespørgsler på din store tabel ved hjælp af et datointerval. Hvis tabellen er hel, vil forespørgslen blive tvunget til at scanne gennem hele tabellen (og i den størrelse kan selv brug af indekser være langsom). Fordelen ved partitionering er, at dine forespørgsler kun kører på de partitioner, hvor det er absolut nødvendigt. Hvis hver partition er 1 GB stor, og din forespørgsel kun skal have adgang til 5 partitioner for at opfylde sig selv, er den kombinerede 5 GB-tabel meget nemmere for MySQL at håndtere end en monsterversion på 42 GB.
En ting, du skal spørge dig selv, er, hvordan du forespørger på dataene. Hvis der er en chance for, at dine forespørgsler kun har brug for at få adgang til bestemte bidder af data (dvs. et datointerval eller id-interval), vil partitionering af en eller anden art vise sig en fordel.
Jeg har hørt, at der stadig er noget buggy med MySQL 5.1-partitionering, især relateret til MySQLs valg af den korrekte nøgle. MERGE-tabeller kan give den samme funktionalitet, selvom de kræver lidt mere overhead.
Håber det hjælper... held og lykke!