Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > MySQL > Насколько важна дефрагментация?


Автор: maxipub 18.11.2014, 12:20
Добрый день!

Кому-то мои вопросы могут опять показаться незначительными. Ребята, мне в первую очередь просто интересно для себя знать! Итак, поехали. smile 

Есть таблица с юзерами, 200к записей, 30Мб весит. В таблице есть такое поле:

`confirm_code` varchar(40) DEFAULT NULL

1.

Это код подтверждения email адреса, который высылается в письме при регистрации. Ну все знают такие штуки. Заполняется рандомом, при успешном подтверждении его значение устанавливается в NULL. Понятно, что при этом возникает фрагментация таблицы (смотрю через phpmyadmin). Но что мне интересно! По мере заполнения таблицы эта фрагментация "мигает". Т.е. кто-то подтвердил регистрацию - она возникла, кто-то новый зарегался - пропала. Как такое может быть? OPTIMIZE TABLE точно ни где нет, 100%. Просто я думал что в MyISAM дефрагментация таблицы сводится к ее блокировке, дампу, и дальнейшему полному восстановлению из дампа и снятия блокировки. Ведь если UPDATE происходит где-то в середине таблицы, оттуда вырезается 40 байт инфы, вставляется NULL - возникает дыра, на которую надо сдвинуть оставшуюся часть файла (или просто перезаписать его целиком заново). Вот не пойму, почему так происходит, чего фрагментация при вставке пропадает? Или перед INSERT принудительно вызывается OPTIMIZE TABLE? Вроде бы нет...

2.

Как в принципе лучше быть? Ставить OPTIMIZE TABLE после каждого UPDATE с confirm_code=NULL ? Просто это каждый раз перезапись 30Мб файл, да еще и блокировать на полсекунды... Прикидываю какая лишняя нагрузка на дисковую подсистему даже при 1000 подобных запросов в день. Не то чтобы капец, но зачем, из-за такой мелочи то!? Лучше повозиться и перенести конфирмкоды в отдельную таблицу, где их просто удалять? Или не стоит на это обращать внимание? smile 

Автор: baldina 18.11.2014, 12:33
в myisam файл данных может иметь свободные блоки (в т.ч. в середине), которые могут использоваться повторно; смежные объединяются в один. это возможно за счет использования внешнего индексного файла.
Цитата(maxipub @  18.11.2014,  12:20 Найти цитируемый пост)
Ставить OPTIMIZE TABLE после каждого UPDATE с confirm_code=NULL

у вас файл 30М весит, это почти ничего по нынешним меркам. не мешайте базе работать.

Автор: Akina 18.11.2014, 12:36
А ты хотя бы понимаешь, что такое фрагментация? в терминах phpmyadmin... 

Автор: baldina 18.11.2014, 12:37
maxipub, если вас все еще беспокоят пустые поля кодов, вынесите их в отдельную таблицу

Автор: maxipub 18.11.2014, 13:12
Цитата(baldina @  18.11.2014,  12:33 Найти цитируемый пост)
в myisam файл данных может иметь свободные блоки (в т.ч. в середине), которые могут использоваться повторно; смежные объединяются в один. это возможно за счет использования внешнего индексного файла.

Т.е. они просто останутся свободными, пока не найдется подходящая инфа для записи туда?

Если так, то эта инфа должна быть только из соседней записи, или туда впихнется любая, подходящая по размеру?

Автор: Akina 18.11.2014, 13:27
Цитата(maxipub @  18.11.2014,  14:12 Найти цитируемый пост)
Т.е. они просто останутся свободными, пока не найдется подходящая инфа для записи туда?

Если не будет превышен предел доли свободного пространства в блоке. Иначе будет выполнено перераспределение.

Цитата(maxipub @  18.11.2014,  14:12 Найти цитируемый пост)
эта инфа должна быть только из соседней записи, или туда впихнется любая, подходящая по размеру? 

При наличии кластерного индекса - нет. Иначе - возможно, да (см. системную переменную concurrent_insert). Поскольку у тебя MyISAM - однозначно второе.

Автор: maxipub 18.11.2014, 13:42
Получается, данные физически в файле будут храниться вперемешку, а не последовательно, и ориентиром на них будет просто индекс?

Автор: Akina 18.11.2014, 13:45
Эммм... http://dev.mysql.com/doc/refman/5.6/en/myisam-storage-engine.html читать не пробовал? там много чего забавного.

Автор: maxipub 18.11.2014, 14:14
Код
Dynamic-sized rows are much less fragmented when mixing deletes with updates and inserts. This is done by automatically combining adjacent deleted blocks and by extending blocks if the next block is deleted.

Речь об этом?

Автор: Akina 18.11.2014, 14:36
Ну и об этом тоже - но в десятую очередь...

Автор: maxipub 18.11.2014, 14:48
Понятно... Мне маны по MySQL даются туго, без примеров. Ну, в общем вопрос решен. Пока не буду париться об этом, а как нечего будет делать, повыношу в отдельные таблицы.

Спасибо!

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)