Чуть ниже в другом комментарии он пишет

9.5 гб

Потому что FK constraint не создался, и БД радостно работает без него, по видимому.
Это возможно, вполне допустимо.

привет, подскажите пожалуйста, в таблице отображается 32000 строк данных, при удалении последних 10 записей, после обновления добавляются новые 10 записей.

не совсем понимаю что происходит, существует какой-то лимит на отображение или что?

Это странно...

вот именно

сам первый раз с таким столкнулся

constraint это что то типа ограничений/условий создания ?

Возможно у тебя база перегружена неадекватным кол-вом индексов

Загрузи куда нибудь структуры таблиц

и дай ссылочку

Ну а в целом тут ssd нужен, да

C какой скоростью дамп загружается в среднем? iotop

Не комитишь может

Ещё можешь включить general_log=1 и посмотреть, может какие то триггера или подключённые системы шалят

кто создаёт сокет?

да

Спасибо за ответ, получается правильным будет добавить столбец с id?

Тут есть разные варианты решения, такой тоже правильный, возможный.

10G 3 часа? скиньте ваш конфиг. у вас размер redo или/и ,innodb_buffer_pool_size не выставлены корректно. вообще, mysqldump это самый медленный способ бэкапить данные. у вас есть другие варианты 1) xtrabackup - физический бэкап 2) mydumper - логический бэкап . если по какой-то причине, вам эти решения не подходят, то вы можете отдельно экспортировать схему, отдельно данные. затем бэкап с данными разбивать потаблично на части и импортировать их (не забудьте выключить проверку fk), но, имхо, это лишние сложности. xtrabackup/mydumper решат проблему. ну и конфиг проверьте - 3 часа это слишком-слишком много, чтобы на это можно было просто закрыть глаза. касательно выжирания места. если с этим есть проблема отключайте slow_log/general_log/binary logs на время импорта