Jag arbetade en gång med en mycket stor (Terabyte+) MySQL-databas. Det största bordet vi hade var bokstavligen över en miljard rader.
Det fungerade. MySQL bearbetade data korrekt för det mesta. Det var dock extremt otympligt.
Att bara säkerhetskopiera och lagra data var en utmaning. Det skulle ta dagar att återställa tabellen om vi behövde.
Vi hade många bord i intervallet 10-100 miljoner rader. Alla betydande anslutningar till borden var för tidskrävande och skulle ta en evighet. Så vi skrev lagrade procedurer för att "gå" i tabellerna och bearbeta joins mot intervall av "id:n". På detta sätt skulle vi bearbeta data 10-100 000 rader åt gången (Join mot id:s 1-100 000 sedan 100 001-200 000, etc). Detta var betydligt snabbare än att gå med mot hela bordet.
Att använda index på mycket stora tabeller som inte är baserade på primärnyckeln är också mycket svårare. Mysql lagrar index i två delar -- det lagrar index (andra än det primära indexet) som index till de primära nyckelvärdena. Så indexerade sökningar görs i två delar:Först går MySQL till ett index och hämtar från det de primära nyckelvärden som den behöver hitta, sedan gör den en andra sökning på primärnyckelindexet för att hitta var dessa värden finns.
Nätet av detta är att för mycket stora tabeller (1-200 miljoner plus rader) är indexering mot tabeller mer restriktiv. Du behöver färre, enklare index. Och att göra även enkla utvalda uttalanden som inte finns direkt på ett index kanske aldrig kommer tillbaka. Där klausuler måste träffa index eller glöm det.
Men allt som sagt, saker och ting fungerade faktiskt. Vi kunde använda MySQL med dessa mycket stora tabeller och göra beräkningar och få svar som var korrekta.