OPTIMIZE TABLE рекомендации использования

[yok]

OPTIMIZE TABLE рекомендации использования

Пишу сценарий, с небольшой базой.
В сценарии происходит удаление записей. При чем немного.
После удаления смотрю статистику по базе и вижу бесполезные затраты ресурсов.

В рекомендации по использованию OPTIMIZE TABLE, говорится что использовать при большом количестве удалений или...

Я же вижу предложение самого сервера об оптимизации и вижу эти расходы(достаточно большие) при небольшом изменении таблицы.

Вопрос:
Если база будет оптимизированна и после каждого удаления произоводить оптимизацию, какая нагрузка на сервер в этот момент, или лучше после многих удалений.

Смысл дефрагментация малодефрагментированного быстра, а если запущено- то и долго. И как сервер к этому относится??

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

 

[Fortop]

... передумал.... у меня не хватит терпения.

 

[Mr_Max]

Если ты говоришь о

небольшой базой

То откуда взялось у тебя

достаточно большые затраты

Что ты имеешь ввиду под большими затратами?

В таблицу вставляется/удаляется 100500 миллионов строк?

 

[yok]

Наверно тут ответ прост, ничто не совершенно в этом мире как и сервер MYSQL, хотя грамотные ответы очень рад был бы услышать.

 

[Mr_Max]

yok
Конкретизируй свой вопрос.

 

[c0dex]

Это мода пошла такая, задать как бы вопрос и самому ответить?

 

[vovanium]

Имхо не тем ты голову забиваешь, делай оптимизацию раз в неделю и будет тебе счастье. Вот когда ты к примеру за раз удалишь половину содержимого таблицы, тогда можно будет задумываться об оптимизации сразу после удаления.

 

[yok]

делай оптимизацию раз в неделю и будет тебе счастье.

Вот наверно пока не разберусь с этим делом так и прийдется поступать.

Наверно если бы были неограниченные ресурсы и по производительности и по обьему, (лгу, все равно бы думал), я бы пустил на самотек.

Пока же мне прийдется поработать над статистикой, и понять алгоритм сервера в этом вопросе , в общих чертах хотя бы .

Пока я не готов предоставить обоснованное суждение.

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

К тому же я прислушиваюсь к мнению большинства, в этом есть смысл всегда.
Спасибо.

 

[vovanium]

yok

Это не значит что я не верю рекомендациям сервера,

Ты так и не сказал о каких размерах таблицы идет речь?
Как выглядят эти рекомендации сервера?

Операции удаления оптимизированы на скорость, т.е. даже физического удаления нет, записи помечаются как удаленные и всё, при оптимизации же полностью перестраивается весь дата-файл. Вот и подумай, что будет с сервером, если ты после каждого мелкого удаления будешь оптимизировать таблицу.

Кроме того ты путаешь дефрагментацию файловой системы, и оптимизацию таблицы, там не совсем идентичные процессы. МуSQL не размазывают одну запись на 100 кусков (просто появляются не используемые "дырки"), плюс работает с одним (несколькими) большим файлом, а не сотнями тысяч мелких, как в случаях с файловой системой.

 

[yok]

Вот спасибо vovanium, за содержательный ответ.

По поводу выражения =рекомендациям сервера верить=, это
допустим отсюда и везде похожее http://www.mysql.ru/docs/man/OPTIMIZE_TABLE.html

4.5.1 Синтаксис команды OPTIMIZE TABLE

OPTIMIZE TABLE tbl_name[,tbl_name]...

Команда OPTIMIZE TABLE должна использоваться после удаления большей части таблицы или если в таблице было внесено много изменений в строки переменной длины (таблицы, в которых есть столбцы VARCHAR, BLOB или TEXT). Удаленные записи поддерживаются при помощи связного списка, и последующие операции INSERT повторно используют позиции старых записей.

рекомендации документации.
Вот и стал вопрос почему так.

У меня еще маленькая таблица, но анализируя, я заметил что (УТОЧНЮ ДУМАЮ), что удаление происходит чтото похоже как в ворде, там в таблице выдели значения и нажми делейт, и значения удаляться, а строка то ОСТАНЕТСЯ. и вес под ней.
Чтото похожее я и увидел в сервере работе.
И твой ответ все решил

Операции удаления оптимизированы на скорость, т.е. даже физического удаления нет, записи помечаются как удаленные и всё

Насчет дефрагментации это я условно сказал, ведь работать легче где порядок, а не бардак.
Спасибо за содержательный ответ.

Кстати , перечитал сейчас и вот заметил, а вчера и не сфокусировался,

Удаленные записи поддерживаются при помощи связного списка, и последующие операции INSERT повторно используют позиции старых записей.

ключевое - повторно используют позиции старых записей.

Вот поэтому они и рекомендуют так, вот это я и хотел узнать, вобщем насчет счастья vovanium, ты был прав.

Всем спасибо и хорошего дня!!!

 

[vovanium]

ты еще не обратил внимание на одно слово

Команда OPTIMIZE TABLE должна использоваться после удаления большей части таблицы

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

 

[yok]

хотя и если ты оптимизируешь через неделю после этого особой разницы не заметишь, если конечно у тебя таблицы не занимает несколько сотен мегабайт.

Да, это точно, при чем если

последующие операции INSERT повторно используют позиции старых записей

тоесть уже какая то оптимизация идет, запись в старые строки, спасибо vovanium, теперь есть свет в конце тонеля.

И период можно расчитывать свой.

Всем удачи.