¿Limitando el número de registros de mysqldump?

137

Estoy tratando de cargar una pequeña muestra de registros de una base de datos grande en una base de datos de prueba.

¿Cómo le dice a mysqldump que solo le dé n registros de 8 millones?

Gracias

mysqldump Phil
fuente

Respuestas:

212

Como dice skaffman, use la opción --where :

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

Por supuesto, eso le daría el primer millón de filas de cada tabla.

Adam Bellaire
fuente
15
¿Qué hace el "1" antes del límite?
Phob
31
@Phob: la opción --where se agrega básicamente a una consulta del formulario SELECT * from table WHERE , por lo que en este caso se obtiene SELECT * from table WHERE 1 limit 1000000. Sin el 1, tendría una consulta no válida. Especificar 1 para una cláusula where (dado que 1 siempre es verdadero) simplemente selecciona todos los registros.
Adam Bellaire
24
Wow, qué truco. Entonces, básicamente, puede inyectarse SQL de esta manera.
Phob
66
¿Mantiene esto todas las integridades de clave externa? Si no, ¿hay alguna manera de hacerlo?
keithxm23
44
¡Gracias! Además, puede usar: mysqldump --opt --where="1 limit 1000000 offset 1000000" --no-create-info database para obtener la segunda página de 1 millón de registros. Asegúrese de usar el indicador --no-create-info en páginas que no sean las primeras para volcar solo los datos y dejar de lado las cosas de la tabla de creación .
pfuri
59

Si desea obtener nregistros de una tabla específica, puede hacer algo como esto:

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

Esto volcará las primeras 1000000filas de la tabla nombrada tableen el archivo dump.sql.

Casper André Casse
fuente
9

mysqldump puede recibir una consulta SQL para ejecutar, de la cual tomará los datos para el volcado. Luego puede usar la cláusula "límite X" en su consulta para restringir el número de filas.

skaffman
fuente
7

Como el orden predeterminado es ASC, que rara vez es lo que desea en esta situación, debe tener un diseño de base de datos adecuado para que DESC funcione de inmediato. Si todas sus tablas tienen UNA columna de clave principal con el mismo nombre (natural o sustituto), puede volcar fácilmente los n últimos registros utilizando:

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

Esta es una razón perfecta por la cual siempre debe nombrar su ID de PK y evitar los PK compuestos, incluso en las tablas de asociación (en su lugar, use claves sustitutas).

Andreas Bergström
fuente
1
Haga esto (identifique el nombre y evite las PK compuestas) y deberá ignorar la teoría de la base de datos relacional.
mpoletto
1
En realidad, si diseña su base de datos siguiendo las mejores prácticas de base de datos relacional, definiendo sus PK basados ​​en datos y entidad, puede usar --option --where = "1 LIMIT 10000" por ejemplo. Sin ORDER BY, esto funcionará porque MySQL ordenará de manera natural, lo que equivale a decir que seguirá el orden de índice de PK. Entonces, todas las FK de las tablas relacionadas tendrán solo datos que existan en la tabla de su referencia porque el orden será el mismo.
mpoletto
El uso de identificaciones es una verdadera plaga de muchos desarrolladores. Tener identificaciones como PK es lo mismo que no tener PK. Su integridad se fue al agujero porque, en la mayoría de los casos, un número de incremento automático no tiene nada que ver con los datos de la entidad.
mpoletto
@mpoletto --where = "1 LIMIT 10000" solo seleccionará las 10000 primeras entradas. El objetivo de mi respuesta fue mostrar cómo resolvería obtener las últimas entradas X, que generalmente es lo que desea. Tampoco entiendo qué tienen que ver las convenciones de nomenclatura con "ignorar la teoría de la base de datos relacional", creo que entendió mal mi respuesta. La mayoría de los ORM populares como EF, Django ORM, etc. prefieren y aconsejan "id" para columnas PK, ya que es redundante decir users.user_id en lugar de solo users.id.
Andreas Bergström
cuando dice que hay una "razón perfecta por la que siempre debe nombrar su ID de PK y evitar los PK compuestos", está ignorando la teoría de la base de datos relacional. Su argumento sobre los "ORM más populares" no es válido porque estos ORM necesitan tablas con ID para funcionar.
mpoletto