Certa vez, trabalhei com um banco de dados MySQL muito grande (Terabyte +). A maior tabela que tínhamos tinha literalmente mais de um bilhão de linhas.

Funcionou. O MySQL processou os dados corretamente na maioria das vezes. Embora fosse extremamente difícil de manejar.

Apenas fazer backup e armazenar os dados era um desafio. Levaria dias para restaurar a mesa se precisássemos.

Tínhamos várias tabelas na faixa de 10 a 100 milhões de linhas. Quaisquer associações significativas às tabelas consumiam muito tempo e levariam uma eternidade. Então, escrevemos procedimentos armazenados para 'andar' pelas tabelas e processar junções contra intervalos de 'id's. Dessa forma, processaríamos os dados de 10 a 100.000 linhas por vez (Junte-se aos ids 1-100.000 e depois 100.001-200.000, etc). Isso foi significativamente mais rápido do que entrar na mesa inteira.

Usar índices em tabelas muito grandes que não são baseadas na chave primária também é muito mais difícil. Mysql armazena índices em duas partes -- ele armazena índices (além do índice primário) como índices para os valores da chave primária. Assim, as pesquisas indexadas são feitas em duas partes:primeiro o MySQL vai para um índice e extrai dele os valores da chave primária que precisa encontrar, depois faz uma segunda pesquisa no índice da chave primária para descobrir onde estão esses valores.

O resultado disso é que, para tabelas muito grandes (1-200 milhões mais linhas), a indexação em relação às tabelas é mais restritiva. Você precisa de menos índices mais simples. E fazer comandos select simples que não estão diretamente em um índice pode nunca mais voltar. Onde as cláusulas devem bater índices ou esquecê-lo.

Mas tudo o que foi dito, as coisas realmente funcionaram. Conseguimos usar o MySQL com essas tabelas muito grandes e fazer cálculos e obter respostas corretas.