Ограничение количества записей из mysqldump?

143

Я пытаюсь загрузить небольшую выборку записей из большой базы данных в тестовую базу данных.

Как вы скажете mysqldump выдать вам только n записей из 8 миллионов?

Благодарность

mysqldump Фил
источник

Ответы:

218

Как говорит скаффман, используйте параметр --where :

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

Конечно, это даст вам первый миллион строк из каждой таблицы.

Адам Беллэр
источник
15
Что делает "1" перед лимитом?
Phob
31
@Phob: Параметр --where обычно добавляется к запросу формы SELECT * from table WHERE , поэтому в этом случае вы получите SELECT * from table WHERE 1 limit 1000000. Без 1 у вас был бы неверный запрос. Указание 1 для предложения where (поскольку 1 всегда истинно) просто выбирает все записи.
Adam Bellaire
25
Вау, что за взлом. Таким образом, вы можете в основном вводить SQL таким образом.
Phob
7
Поддерживает ли это целостность внешнего ключа? Если нет, есть ли способ это сделать?
keithxm23
4
Благодарность! Дополнительно вы можете использовать: mysqldump --opt --where="1 limit 1000000 offset 1000000" --no-create-info database чтобы получить вторую страницу из 1 миллиона записей. Убедитесь, что вы используете флаг --no-create-info на всех страницах, кроме первой, чтобы выгрузить только данные и исключить создание таблицы .
pfuri
61

Если вы хотите получить nзаписи из определенной таблицы, вы можете сделать что-то вроде этого:

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

Это приведет к сбросу первых 1000000строк из указанной таблицы tableв файл dump.sql.

Каспер Андре Касс
источник
9

mysqldump может получить SQL-запрос для выполнения, из которого он будет брать данные для дампа. Затем вы можете использовать в своем запросе предложение «limit X», чтобы ограничить количество строк.

Скаффман
источник
8

Поскольку порядок по умолчанию - ASC, который редко бывает тем, что вам нужно в этой ситуации, вам необходимо иметь правильный дизайн базы данных, чтобы DESC работал из коробки. Если все ваши таблицы имеют ОДИН столбец первичного ключа с тем же именем (естественным или суррогатным), вы можете легко выгрузить n последних записей, используя:

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

Это прекрасная причина, по которой вы всегда должны называть свой идентификатор PK и избегать составных PK, даже в таблицах ассоциаций (вместо этого используйте суррогатные ключи).

Андреас Бергстрём
источник
1
Сделайте это (назовите id и избегайте составных PK), и вам придется игнорировать теорию реляционных баз данных.
mpoletto
1
На самом деле, если вы проектируете свою базу данных в соответствии с лучшими практиками реляционной базы данных, определяя ПК на основе данных и сущности, вы можете, например, использовать --option --where = "1 LIMIT 10000". Без ORDER BY это будет работать, потому что MySQL будет упорядочивать естественным образом, что эквивалентно тому, что он будет следовать порядку индекса PK. Тогда все FK связанных таблиц будут иметь только данные, существующие в их справочной таблице, потому что порядок будет таким же.
mpoletto
Использование ID - настоящая чума для многих разработчиков. Иметь такие идентификаторы как ПК - это то же самое, что и не иметь ПК. Ваша целостность была нарушена, потому что в большинстве случаев автоматически увеличивающееся число не имеет ничего общего с данными объекта.
mpoletto
@mpoletto --where = "1 LIMIT 10000" выберет только первые 10000 записей. Вся суть моего ответа заключалась в том, чтобы показать, как вы решите получить последние X-записи, а это обычно то, что вам нужно. Я также не понимаю, какое отношение соглашения об именах имеют к «игнорированию теории реляционных баз данных», я думаю, вы неправильно поняли мой ответ. Наиболее популярные ORM, такие как EF, Django ORM и т. Д., По умолчанию используют "id" для столбцов PK, поскольку указывать users.user_id вместо просто users.id является избыточным.
Андреас Бергстрём
когда вы говорите, что существует «веская причина, по которой вы всегда должны называть свой идентификатор PK и избегать составных PK», вы игнорируете теорию реляционных баз данных. Ваш аргумент о «самых популярных ORM» недействителен, потому что этим ORM для работы нужны таблицы с идентификаторами.
mpoletto