mysqldump создает больше строк, чем фактический диапазон первичного ключа - PullRequest
Новая
       7

mysqldump создает больше строк, чем фактический диапазон первичного ключа

0 голосов
/ 16 декабря 2018

У меня есть таблица длиной примерно 290 000 строк.До резервного копирования, вероятно, потребовалось <200 МБ.Когда я создал резервную копию этой таблицы, используя <code>mysqldump, файл резервной копии занимает ~ 800 МБ, а когда я перезагружаюсь из файла резервной копии, используя mysql, я теперь вижу, что он имеет ~ 430 000 строк, что намного больше, чем в исходной таблице(Я проверяю через HeidiSQL UI).Но если я сделаю запрос по полному диапазону первичного ключа, он будет таким же, как и у старой таблицы (~ 290 000).Что могло пойти не так?

Вот код CREATE для конкретной рассматриваемой таблицы.Это просто список переменных (типа DECIMAL) 

    CREATE TABLE `ciceroout` (
    `runID` INT(11) NOT NULL AUTO_INCREMENT,
    `IterationNum` DECIMAL(20,10) NULL DEFAULT NULL,
    `IterationCount` DECIMAL(20,10) NULL DEFAULT NULL,
    `RunningCounter` DECIMAL(20,10) NULL DEFAULT NULL,
    \* more 100 variables like this *\
    PRIMARY KEY (`runID`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
AUTO_INCREMENT=287705
;

РЕДАКТИРОВАТЬ: Вот фактические команды дампа и восстановления, которые я использовал.В нашей базе данных есть шесть таблиц, и я уже выгрузил одну таблицу, поэтому здесь я выгружаю остальные пять таблиц.

таблицы дампа: 

 mysqldump -u root --single-transaction=true --verbose -p [dbname] --ignore-table=[dbname].images > \path\[backupname].sql

таблицы восстановления (после удаления исходной базы данных иначиная с пустого): 

mysql -u root -p [db name] < \path\[backupname].sql

и вот что я вижу в HeidiSQL UI enter image description here

Ответы [ 2 ]

0 голосов
/ 17 декабря 2018

Допустим, вы выгружаете INT, который является 4-байтовым количеством в базе данных. 

Value = 1 -- dump contains ...,1,... -- effectively 2 bytes.
value = -1222333444 -- dump contains ...,-1222333444,... -- 12 bytes

С этими примерами вы видите, что INT может занять от половины допространство и в 3 раза больше места при сбросе.(Другие типы данных приводят к другим примерам.)

"280K строк" является точным и не изменится, пока вы не INSERT / DELETE строк.«430K», как уже упоминалось, является приблизительным.

Фактическое дисковое пространство могло увеличиться или немного уменьшиться после выгрузки и загрузки.Это связано с большим количеством факторов.

Нам просто нужно смириться с этими не очень важными несоответствиями.

SHOW TABLE STATUS - это еще один способ увидеть дисковое пространство.

Я считаю "счетчики" целыми числами.Есть ли какая-то причина для того, чтобы иметь 10 десятичных знаков на этом: 

RunningCounter` DECIMAL(20,10)

Изменение всех этих значений на INT приведет к сокращению каждого столбца с 10 байтов до 4 байтов.Это сократит использование диска в два раза.

0 голосов
/ 16 декабря 2018

Если вас интересует большой файл экспорта: это нормально.
Данные хранятся в удобочитаемом формате (SQL), тогда как фактические данные в табличном пространстве хранятся в гораздо более эффективной структуре данных (B + Tree)

Относительно статистики таблицы, которую показывает HeidiSQLyou:
Для InnoDB статистика "количества строк" является всего лишь приближением .

. Результат COUNT(*) дает вам реальное количество строк, которое соответствуеторигинал, верно?

Приближение со временем будет меняться и улучшаться, когда вы начнете работать с данными.

Страница справки MySQL для ПОКАЗАТЬ СТАТУС сообщает:

Количество строк.Некоторые механизмы хранения, такие как MyISAM, хранят точное количество.Для других механизмов хранения, таких как InnoDB, это значение является приблизительным и может отличаться от фактического значения на целых 40-50%.В таких случаях используйте SELECT COUNT (*), чтобы получить точный счет.

...