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.
Respostas:
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:
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.
EXPLAIN- novatos ou não.
EXPLAIN ;)
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:
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.
SELECT LAST_INSERT_ID()vez dessa consulta.
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.