Limiter le nombre d'enregistrements de mysqldump?

137

J'essaie de charger un petit échantillon d'enregistrements d'une grande base de données dans une base de données de test.

Comment dire à mysqldump de ne vous donner que n enregistrements sur 8 millions?

Merci

mysqldump Phil
la source

Réponses:

212

Comme le dit skaffman, utilisez l' option --where :

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

Bien sûr, cela vous donnerait le premier million de lignes de chaque table.

Adam Bellaire
la source
15
Que fait le "1" avant la limite?
Phob
31
@Phob: L'option --where est essentiellement ajoutée à une requête du formulaire SELECT * from table WHERE , donc dans ce cas, vous obtenez SELECT * from table WHERE 1 limit 1000000. Sans le 1, vous auriez une requête non valide. Spécifier 1 pour une clause where (puisque 1 est toujours vrai) sélectionne simplement tous les enregistrements.
Adam Bellaire
24
Wow, quel hack. Vous pouvez donc vous injecter du SQL de cette façon.
Phob
6
Cela permet-il de conserver toutes les intégrations de clés étrangères? Sinon, y a-t-il un moyen de le faire?
keithxm23
4
Merci! De plus, vous pouvez utiliser: mysqldump --opt --where="1 limit 1000000 offset 1000000" --no-create-info database pour obtenir la deuxième page de 1 million d'enregistrements. Assurez-vous d'utiliser l' indicateur --no-create-info sur les pages autres que la première pour vider uniquement les données et laisser de côté les éléments de création de table .
pfuri
59

Si vous souhaitez obtenir des nenregistrements à partir d'une table spécifique, vous pouvez faire quelque chose comme ceci:

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

Cela videra les premières 1000000lignes de la table nommée tabledans le fichier dump.sql.

Casper André Casse
la source
9

mysqldump peut recevoir une requête SQL à exécuter, à partir de laquelle il prendra les données pour le vidage. Vous pouvez ensuite utiliser la clause «limit X» dans votre requête pour limiter le nombre de lignes.

skaffman
la source
7

Comme l'ordre par défaut est ASC, ce qui est rarement ce que vous voulez dans cette situation, vous devez avoir une conception de base de données appropriée pour que DESC fonctionne immédiatement. Si toutes vos tables ont UNE colonne de clé primaire avec le même nom (naturel ou substitut), vous pouvez facilement vider les n derniers enregistrements en utilisant:

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

C'est une raison parfaite pour laquelle vous devriez toujours nommer l' id de votre PK et éviter les PK composites, même dans les tables d'association (utilisez plutôt des clés de substitution).

Andreas Bergström
la source
1
Faites ceci (nommez l'id et évitez les PK composites) et vous devrez ignorer la théorie des bases de données relationnelles.
mpoletto
1
En fait, si vous concevez votre base de données en suivant les meilleures pratiques de la base de données relationnelle, en définissant vos PK en fonction des données et de l'entité, vous pouvez utiliser --option --where = "1 LIMIT 10000" par exemple. Sans ORDER BY, cela fonctionnera car MySQL ordonnera de manière naturelle, ce qui équivaut à dire qu'il suivra l'ordre d'index du PK. Ensuite, tous les FK des tables liées auront uniquement des données qui existent dans la table de leur référence car l'ordre sera le même.
mpoletto
L'utilisation d'identifiants est un véritable fléau pour de nombreux développeurs. Avoir des ID comme PK est la même chose que ne pas avoir de PK. Votre intégrité était au plus bas car, dans la plupart des cas, un numéro d'incrémentation automatique n'a rien à voir avec les données d'entité.
mpoletto
@mpoletto --where = "1 LIMIT 10000" ne sélectionnera que les 10000 premières entrées. Le but de ma réponse était de montrer comment vous résoudriez l'obtention des dernières entrées X, ce que vous voulez généralement. Je ne comprends pas non plus ce que les conventions de nommage ont à voir avec "ignorer la théorie des bases de données relationnelles", je pense que vous avez mal compris ma réponse. Les ORM les plus populaires comme EF, Django ORM, etc. utilisent par défaut et conseillent "id" pour les colonnes PK, car il est redondant de dire users.user_id au lieu de juste users.id.
Andreas Bergström
quand vous dites qu'il y a une «raison parfaite pour laquelle vous devriez toujours nommer votre identifiant PK et éviter les PK composites», vous ignorez la théorie des bases de données relationnelles. Votre argument concernant les "ORM les plus populaires" n'est pas valide, car ces ORM ont besoin de tables avec des ID pour fonctionner.
mpoletto