Limitare il numero di record da mysqldump?

137

Sto cercando di caricare un piccolo campione di record da un database di grandi dimensioni in un database di prova.

Come dici a mysqldump di darti solo n record su 8 milioni?

Grazie

mysqldump

212

Come dice skaffman, usa l' opzione --where :

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

Naturalmente, ciò ti darebbe il primo milione di righe da ogni tabella.

— Adam Bellaire
fonte

15

Cosa fa "1" prima del limite?

— Phob,

31

@Phob: L'opzione --where viene sostanzialmente aggiunta a una query del modulo SELECT * from table WHERE , quindi in questo caso ottieni SELECT * from table WHERE 1 limit 1000000. Senza il 1, si avrebbe una query non valida. Specificare 1 per una clausola where (poiché 1 è sempre true) seleziona semplicemente tutti i record.

— Adam Bellaire,

24

Wow, che hack. Quindi puoi praticamente iniettarti SQL in questo modo.

— Phob,

6

Questo mantiene tutte le integrità delle chiavi esterne? In caso contrario, c'è un modo per farlo?

— keithxm23,

4

Grazie! Inoltre, è possibile utilizzare: mysqldump --opt --where="1 limit 1000000 offset 1000000" --no-create-info database per ottenere la seconda pagina di 1 milione di record. Assicurati di usare il flag --no-create-info su pagine diverse dalla prima per scaricare solo i dati e lasciare le cose della tabella di creazione .

— pfuri,

59

Se vuoi ottenere nrecord da una tabella specifica puoi fare qualcosa del genere:

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

Ciò scaricherà le prime 1000000righe dalla tabella denominata tablenel file dump.sql.

— Casper André Casse
fonte

9

mysqldump può ricevere una query SQL da eseguire, dalla quale prenderà i dati per il dump. È quindi possibile utilizzare la clausola "limit X" nella query per limitare il numero di righe.

— skaffman
fonte

7

Poiché l'ordine predefinito è ASC, che raramente è ciò che si desidera in questa situazione, è necessario disporre di una corretta progettazione del database per far funzionare DESC immediatamente. Se tutte le tue tabelle hanno UNA colonna chiave primaria con lo stesso nome (naturale o surrogato) puoi facilmente scaricare gli ultimi record usando:

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

Questo è un motivo perfetto per cui dovresti sempre nominare l' id del tuo PK ed evitare i PK compositi, anche nelle tabelle di associazione (usa invece le chiavi surrogate).

— Andreas Bergström
fonte

1

Fai questo (nome id ed evita i PK compositi) e dovrai ignorare la teoria del database relazionale.

— mpoletto,

1

In realtà, se progetti il tuo database seguendo le migliori pratiche del database relazionale, definendo i tuoi PK basati su dati ed entità, puoi usare --option --where = "1 LIMIT 10000" per esempio. Senza ORDER BY, questo funzionerà perché MySQL ordinerà in modo naturale, il che equivale a dire che seguirà l'ordine dell'indice del PK. Quindi, tutti gli FK delle tabelle correlate avranno solo i dati esistenti nella tabella dei loro riferimenti perché l'ordine sarà lo stesso.

— mpoletto,

L'uso degli ID è una vera piaga per molti sviluppatori. Avere ID come PK è lo stesso di non avere PK. La tua integrità è stata messa a dura prova perché, nella maggior parte dei casi, un numero di incremento automatico non ha nulla a che fare con i dati dell'entità.

— mpoletto,

@mpoletto --where = "1 LIMIT 10000" sceglierà solo le prime 10000 voci. Il punto centrale della mia risposta era mostrare come risolveresti ottenendo le ultime voci X, che di solito è quello che vuoi. Inoltre non capisco cosa abbiano a che fare le convenzioni di denominazione con "l'ignoramento della teoria dei database relazionali", penso che tu abbia frainteso la mia risposta. ORM più popolari come EF, Django ORM, ecc. Utilizzano e consigliano di default "id" per le colonne PK, poiché è ridondante dire users.user_id anziché solo users.id.

— Andreas Bergström,

quando dici che c'è un "motivo perfetto per cui dovresti sempre nominare il tuo ID PK ed evitare il PK composito" stai ignorando la teoria del database relazionale. La tua argomentazione sugli "ORM più popolari" non è valida perché questi ORM hanno bisogno di tabelle con ID per funzionare.

— mpoletto,