Limitando o número de registros do mysqldump?

137

Estou tentando carregar uma pequena amostra de registros de um banco de dados grande em um banco de dados de teste.

Como você diz ao mysqldump para fornecer apenas n registros de 8 milhões?

obrigado

mysqldump

212

Como diz skaffman, use a opção --where :

mysqldump --opt --where="1 limit 1000000" database

Claro, isso daria o primeiro milhão de linhas de todas as tabelas.

— Adam Bellaire
fonte

15

O que o "1" antes do limite faz?

— Phob

31

@ Phob: A opção --where é basicamente anexada a uma consulta do formulário SELECT * from table WHERE , portanto, neste caso, você recebe SELECT * from table WHERE 1 limit 1000000. Sem o 1, você teria uma consulta inválida. Especificar 1 para uma cláusula where (como 1 é sempre verdadeiro) simplesmente seleciona todos os registros.

— Adam Bellaire

24

Uau, que truque. Então, você pode basicamente SQL se injetar dessa maneira.

— Phob 15/07/11

6

Isso mantém todas as integridades de chave estrangeira? Se não, existe uma maneira de fazer isso?

— keithxm23

4

Obrigado! Além disso, você pode usar: mysqldump --opt --where="1 limit 1000000 offset 1000000" --no-create-info database para obter a segunda página de 1 milhão de registros. Certifique-se de usar o sinalizador --no-create-info em páginas diferentes da primeira para despejar apenas os dados e deixar de fora as coisas da tabela de criação .

— precisa saber é o seguinte

59

Se você deseja obter nregistros de uma tabela específica, pode fazer algo assim:

mysqldump --opt --where="1 limit 1000000" database table > dump.sql

Isso irá despejar as primeiras 1000000linhas da tabela nomeada tableno arquivo dump.sql.

— Casper André Casse
fonte

9

O mysqldump pode receber uma consulta SQL para executar, a partir da qual os dados serão retirados. Você pode usar a cláusula "limit X" na sua consulta para restringir o número de linhas.

— skaffman
fonte

7

Como o pedido padrão é ASC, o que raramente é o que você deseja nessa situação, é necessário ter um design de banco de dados adequado para fazer com que o DESC funcione imediatamente. Se todas as suas tabelas tiverem UMA coluna de chave primária com o mesmo nome (natural ou substituto), você poderá despejar facilmente os n registros mais recentes usando:

mysqldump --opt --where="1 ORDER BY id DESC limit 1000000" --all-databases > dump.sql

Esse é um motivo perfeito para você sempre nomear o ID de sua PK e evitar PKs compostas, mesmo em tabelas de associação (use chaves substitutas).

— Andreas Bergström
fonte

1

Faça isso (nomeie a identificação e evite PKs compostas) e você precisará ignorar a teoria do banco de dados relacional.

— mpoletto

1

Na verdade, se você projetar seu banco de dados seguindo as práticas recomendadas de banco de dados relacional, definindo suas CPs com base em dados e entidade, poderá usar --option --where = "1 LIMIT 10000", por exemplo. Sem ORDER BY, isso funcionará porque o MySQL ordenará de maneira natural, o que equivale a dizer que seguirá a ordem de índice do PK. Então, todos os FK de tabelas relacionadas terão apenas dados que existem na tabela de referência porque a ordem será a mesma.

— mpoletto

O uso de IDs é uma verdadeira praga de muitos desenvolvedores. Ter IDs como PK's é o mesmo que não ter PK's. Sua integridade foi prejudicada porque, na maioria dos casos, um número de incremento automático não tem nada a ver com os dados da entidade.

— mpoletto

@mpoletto --where = "1 LIMIT 10000" selecionará apenas as 10000 primeiras entradas. O ponto principal da minha resposta foi mostrar como você resolveria obter as entradas mais recentes do X, que geralmente é o que você deseja. Também não entendo o que as convenções de nomenclatura têm a ver com "ignorar a teoria do banco de dados relacional"; acho que você não entendeu minha resposta. ORMs mais populares, como EF, Django ORM, etc. padronizam e aconselham "id" para colunas PK, pois é redundante dizer users.user_id em vez de apenas users.id.

— Andreas Bergström

quando você diz que existe uma "razão perfeita para você sempre nomear seu ID de PK e evitar PKs compostos", está ignorando a teoria do banco de dados relacional. Seu argumento sobre "ORMs mais populares" não é válido porque esses ORMs precisam de tabelas com IDs para funcionar.

— mpoletto