Бд MySql, таблички innodb, в конфиге innodb_file_per_table=1, т.е. для каждой таблички создается отдельный файлик, так надо, так удобно, удалил табличку удалился файлик, освободилось место. В БД очень часто пишутся и удаляются данные. По стате 35% запросов это insert и 18% delete Все вроде хорошо, кроме одного, объясню на пальцах (цифры условные): Допустим была таблица на 5 миллионов записей, весом 10 Гигов. В какой то момент прилетает запрос delete и сносит 2 ляма записей, таблица, де факто, уменьшается на 5 гигов, т.е. физически, если ее скопировать в другую таблицу, она будет весить 5 гигов в не 10. НО! Файлик table_name.ibd как был 10 гигов, так и остался, т.е. он может только расти, уменьшаться нет. И сервер видит его как 10 гигабайтный....вобщем места не напасешься в таких условиях ( Может кто знает как изъебнуться еще, кроме копирования, сноса старой и переименования скопированной освободить место на диске? Может есть какая настройка innodb которую я прошляпил?
Они не удаляются а идут как резерв восстановлений. Недаром авто инкремент продолжает считать пропуская удаленку. Форматирование, дефрагментация таблиц есть и т.д. Все тоже самое как и с HDD когда выбираем функцию Optimize SSD
Это оооочень длительный процесс и чтоб его выполнить я должен "остановить" работу БД, дабы не потерять данные, а я не могу этого сделать.
1. никто не рекомендует ничего вырубать 2. @Dmitriy A. Arteshuk погугли, может там есть чо в гуглах этих про почистку таблицы и оптимизацию её или типа того. наверняка.
Они не удаляются, что бы избежать лишней фрагментации таблиц и индексов, а автоинкремент пропускает удаленку, что бы исключить возможность дублирования id. А вообще, в postgre есть autovacuum, который в фоне всем этим занимается, есть ли такое в mysql даже хз.
В InnoDB DELETE не удаляет записи физически, а только помечает их как удалённые. Насколько я понимаю, это это сделано специально, чтобы исключить самые медленные операции - дисковые. Соответственно, размер файла не изменяется. Для физического удаления есть отдельные операторы (optimize, например). Но это очень медленная штука - для 10 гигов на медленных дисках это может занять до двух часов времени. Можно извратится, как ты написал, через копирование и переименовывание - это ускорит дело, но не до секунд (предположительно, десятки минут - не проверял). Ещё вариант, если добавление/удаление используется для расчётов (т.е. как временное явление), то имеет смысл использовать временную таблицу (т.е. скопировал, обработал, удалил). Для рабочей (постоянно используемой) таблицы есть правильное решение, - оставь как есть. Т.е. не нужно физически удалять записи, если в этом нет явной необходимости. Дело в том, что INSERT использует место, занятое логически удалёнными записями заново. Грубо говоря, если 2 млн. записей сначала удалено, а затем добавлено, то размер файла не изменится. Кстати, стоит помнить, что ещё есть фрагментация файлов (чем больше фрагментирован файл, тем медленнее его чтение), поэтому изредка нужно дефрагментировать файлы БД. Кстати-2, в т.ч. поэтому Per-Table Tablespaces медленнее, чем системная табличная область. Если нужна максимальная скорость - не используйте Per-Table. п.с. Естественно, всё зависит от приоритетов. Если место на диске важнее, чем скорость, то от упаковки никуда не денешься. Рекомендуется её делать как можно реже (т.е. когда явно необходимо). Если и есть, то в доке нет её описания. По крайней мере, мне не попадалось.
Спасибо всем за мнения и размышления! ) Да, все именно так, но вот получилась такая ситуация, что удалилось куда больше чем пришло ( И когда там придет столько же непонятно, а место на сервере стремительно подходит к концу ( Честно говоря не уверен в этом, но не проверял поэтому возражать не буду. Конкретно в моей системе мне нужно именно под каждую табличку свои файлики. Дело в том, что есть таблицы статистики, в них что то постоянно пишется, и я не могу остановить работу сервера или БД ( OPTIMIZE TABLE на таблице в 15 гигов у меня отработал примерно за час. Есть таблицы, которые я могу "контролировать" и ТОЧНО знаю что в это время ничего в нее не пишется и не удаляется. Таких таблиц несколько, в результате мне удалось без остановки сервера или БД "наковырять" почти 10 гигов места ) Всем спасибо еще раз! ) --- Добавлено --- Да, насчет копирования, по времени то же самое что и OPTIMIZE ибо и то и другое запись таблицы на диск
Если про дефрагментацию, то однозначно фрагментируются и число фрагментов могут быть сотни. Конечно это зависит от файловой системы, но что-то я не припомню такую, которая пишет без фрагментов. А зачем? Поделись страшным секретом. IMHO, в этом режиме есть только один смысл - считать реальный объём файлов для каждой БД в отдельности. Актуально, например, для общественного хостинга, где каждый платит за свой объём. Ну, если изначально был Per-Table и нельзя изменять почему-то, тогда конечно. --- Добавлено --- Не всё так просто. Если в файле есть вторичные индексы, то OPTIMIZE как правило медленнее, чем копирование без втор.индексов + создание этих индексов. В зависимости от конкретики разница может быть до 2-х и даже более раз.