Quantas linhas em um banco de dados são MUITAS?

Tenho uma tabela MySQL InnoDB com 1.000.000 de registros. Isso é demais? Ou os bancos de dados podem lidar com isso e muito mais? Eu pergunto porque percebi que algumas consultas (por exemplo, obter a última linha de uma tabela) são mais lentas (segundos) na tabela com 1 milhão de linhas do que em uma com 100.

Tenho uma tabela MySQL InnoDB com 1.000.000 de registros. Isso é demais?

Não, 1.000.000 de linhas (registros AKA) não é muito para um banco de dados.

Eu pergunto porque percebi que algumas consultas (por exemplo, obter o último registro de uma tabela) são mais lentas (segundos) na tabela com 1 milhão de registros do que em uma com 100.

Há muito a ser explicado nessa declaração. Os suspeitos do costume são:

1. Consulta mal escrita
2. Não usando uma chave primária, assumindo que ainda exista uma na mesa
3. Modelo de dados mal projetado (estrutura de tabela)
4. Falta de índices

Tenho um banco de dados com mais de 97 milhões de registros ( 30GB datafile ), e não tenho problemas.

Apenas lembre-se de definir e melhorar o índice da sua tabela .

Portanto, é óbvio que 1.000.000 não são MUITOS! (Mas se você não indexar; sim, são MUITOS)

Use 'explain' para examinar sua consulta e ver se há algo errado com o plano de consulta.

Acho que isso é um equívoco comum - o tamanho é apenas uma parte da equação quando se trata de escalabilidade do banco de dados. Existem outros problemas que são difíceis (ou mais difíceis):

• Qual é o tamanho do conjunto de trabalho (ou seja, quantos dados precisam ser carregados na memória e trabalhados ativamente). Se você apenas inserir dados e não fizer nada com eles, é realmente um problema fácil de resolver.

• Qual nível de simultaneidade é necessário? Existe apenas um usuário inserindo / lendo ou temos muitos milhares de clientes operando ao mesmo tempo?

• Que níveis de promessa / durabilidade e consistência de desempenho são necessários? Temos que ter certeza de que podemos honrar cada compromisso. Tudo bem se a transação média for rápida ou queremos ter certeza de que todas as transações são confiáveis ​​e rápidas (controle de qualidade seis sigma como - http://www.mysqlperformanceblog.com/2010/06/07/performance-optimization- e-seis-sigma / ).

• Você precisa fazer algum problema operacional, como ALTER o esquema da tabela? No InnoDB isso é possível, mas incrivelmente lento, uma vez que geralmente é necessário criar uma tabela temporária em primeiro plano (bloqueando todas as conexões).

Portanto, vou declarar que as duas questões limitantes serão:

• Sua própria habilidade em escrever consultas / ter bons índices.
• Quanta dor você pode tolerar esperando pelas instruções ALTER TABLE.

Se você quer dizer 1 milhão de linhas, isso depende de como sua indexação é feita e da configuração de seu hardware. Um milhão de linhas não é uma grande quantidade para um banco de dados corporativo, ou mesmo um banco de dados de desenvolvimento em um equipamento decente.

se você quer dizer 1 milhão de colunas (não tenho certeza se isso é possível no MySQL), então sim, isso parece um pouco grande e provavelmente causará problemas.

Registro? Você quer dizer gravar?

Um milhão de registros não é um grande problema para um banco de dados nos dias de hoje. Se você encontrar algum problema, provavelmente não é o sistema de banco de dados em si, mas sim o hardware em que você o está executando. Provavelmente, você não terá problemas com o banco de dados antes de ficar sem hardware para usá-lo.

Agora, obviamente, algumas consultas são mais lentas do que outras, mas se duas consultas muito semelhantes forem executadas em tempos muito diferentes, você precisa descobrir qual é o plano de execução do banco de dados e otimizá-lo, ou seja, usar índices corretos, normalização adequada, etc.

A propósito, não existe "último" registro em uma tabela, do ponto de vista lógico eles não têm uma ordem inerente.

Já vi tabelas não particionadas com vários bilhões de registros (indexados), que se auto-juntaram para trabalho analítico. Nós eventualmente dividimos a coisa, mas honestamente não vimos muita diferença.

Dito isso, isso foi no Oracle e não testei esse volume de dados no MySQL. Os índices são seus amigos :)

Supondo que você queira dizer "registros" por "registros", não, não é muito, o MySQL é muito bem dimensionado e pode armazenar tantos registros quantos forem necessários em seu disco rígido.

Obviamente, as consultas de pesquisa serão mais lentas. Não há realmente nenhuma maneira de contornar isso, exceto certificar-se de que os campos estão devidamente indexados.

Quanto maior a tabela fica (como em mais linhas nela), as consultas mais lentas normalmente serão executadas se não houver índices. Depois de adicionar os índices corretos, o desempenho da consulta deve melhorar ou, pelo menos, não degradar tanto quanto a tabela cresce. No entanto, se a própria consulta retornar mais linhas conforme a tabela fica maior, você começará a ver degradação novamente.

Embora 1 milhão de linhas não sejam tantos, também depende de quanta memória você tem no servidor de banco de dados. Se a tabela for muito grande para ser armazenada em cache na memória pelo servidor, as consultas serão mais lentas.

Usar a consulta fornecida será excepcionalmente lento devido ao uso de um método de mesclagem de classificação para classificar os dados.

Eu recomendaria repensar o design para que você use índices para recuperá-lo ou certifique-se de que ele já esteja ordenado dessa maneira, de forma que nenhuma classificação seja necessária.