mysqldumpからのレコード数を制限しますか？

137

大規模なデータベースからテストデータベースにレコードの小さなサンプルをロードしようとしています。

mysqldumpに800万のうちn個のレコードのみを与えるようにするにはどうすればよいですか？

ありがとう

mysqldump

212

skaffmanが言うように、-whereオプションを使用します。

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

もちろん、すべてのテーブルから最初の100万行が得られます。

— アダム・ベレア
ソース

15

制限前の「1」は何をしますか？

— フォブ

31

@Phob：--whereオプションは基本的にフォームのクエリに追加されるSELECT * from table WHERE ため、この場合はになりSELECT * from table WHERE 1 limit 1000000ます。1がないと、クエリが無効になります。where句に1を指定すると（1は常にtrueであるため）、単にすべてのレコードが選択されます。

— Adam Bellaire、2011

24

うわー、なんとハック。したがって、基本的にはSQLをこの方法で注入できます。

— フォブ

6

これはすべての外部キーの整合性を維持しますか？そうでない場合、それを行う方法はありますか？

— keithxm23 2012年

4

ありがとう！さらに、以下を使用できます。100 mysqldump --opt --where="1 limit 1000000 offset 1000000" --no-create-info database 万レコードの2ページ目を取得する。最初のページ以外のページで--no-create-infoフラグを使用して、データのみをダンプし、テーブルの作成などは行わないようにしてください。

— pfuri 2017

59

n特定のテーブルからレコードを取得する場合は、次のようなことができます。

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

これにより、1000000指定tableしたテーブルの最初の行がファイルにダンプされますdump.sql。

— キャスパーアンドレキャス
ソース

9

mysqldumpには、実行するSQLクエリを指定でき、そこからダンプのデータを取得します。次に、クエリで "limit X"句を使用して、行数を制限できます。

— スカフマン
ソース

6

デフォルトの順序はASCであるため、この状況ではほとんど必要ありません。DESCをそのまま使用できるようにするには、適切なデータベース設計が必要です。すべてのテーブルに同じ名前（自然またはサロゲート）の主キー列が1つある場合、次のコマンドを使用してn個の最新のレコードを簡単にダンプできます。

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

これは、関連付けテーブルでも、常にPKのIDに名前を付けて、複合PKを避けなければならない完全な理由です（代わりに代理キーを使用してください）。

— アンドレアス・ベルクストロム
ソース

1

これを行い（IDに名前を付け、複合PKを避けます）、リレーショナルデータベースの理論を無視する必要があります。

— mpoletto

1

実際、リレーショナルデータベースのベストプラクティスに従ってデータベースを設計し、データとエンティティに基づいてPKを定義する場合、たとえば--option --where = "1 LIMIT 10000"を使用できます。ORDER BYがなければ、MySQLが自然な方法で順序付けされるため、これは機能します。これは、PKのインデックス順序に従うということと同じです。次に、順序が同じになるため、関連するテーブルのすべてのFKには、参照のテーブルに存在するデータのみが含まれます。

— mpoletto

IDの使用は、多くの開発者にとって真の問題です。PKのようなIDを持つことは、PKがないことと同じです。ほとんどの場合、自動インクリメント番号はエンティティデータとは関係がないため、整合性が失われました。

— mpoletto

@mpoletto --where = "1 LIMIT 10000"は、10000個の最初のエントリのみを選択します。私の回答の要点は、最新のXエントリの取得をどのように解決するかを示すことでした。これは通常、必要なことです。また、命名規則が「リレーショナルデータベース理論を無視する」とどのように関係しているのかもわかりません。私の答えを誤解していると思います。EFやDjango ORMなどの最も人気のあるORMは、users.idだけでなくusers.user_idと言うのは冗長であるため、デフォルトでPK列の「id」を推奨します。

— AndreasBergström2017年

「常にPKのIDに名前を付けて、複合PKを避けなければならない理由には完全な理由がある」とあなたが言うとき、あなたはリレーショナルデータベース理論を無視しています。「最も人気のあるORM」についてのあなたの議論は、このORMが機能するためにIDを持つテーブルを必要とするため無効です。

— mpoletto 2017年