В руководство говорит про "оптимизировать таблицу":
«Удаленные строки сохраняются в связанном списке, а последующие операции INSERT повторно используют старые позиции строк. Вы можете использовать OPTIMIZE TABLE, чтобы освободить неиспользуемое пространство и дефрагментировать файл данных».
Итак, я предполагаю, что будет некоторый прирост производительности, даже если носитель данных - SSD (поскольку связанный список удаленных строк будет удален). OTOH (просто догадываюсь) прирост производительности не будет таким значительным, как для жесткого диска, который также выиграет от более быстрого последовательного чтения после запуска оптимизации.
Так стоит ли запускать оптимизацию в этой ситуации? Будет ли прирост производительности достаточно значительным, чтобы перевесить сокращение ожидаемого срока службы SSD (из-за ненужного переупорядочивания хранимых данных) ?. Я говорю о таблицах, которые в остальном являются идеальным кандидатом для оптимизации (имеющие строки переменной длины с частыми обновлениями).
Есть еще кое-что, что следует учитывать при использовании ОПТИМИЗАЦИЯ ТАБЛИЦЫ
Какой Storage Engine вы используете, MyISAM или InnoDB ???
Если вы используете MyISAM, вы действительно можете восстановить значительный объем дискового пространства, если таблица MyISAM подвергается множеству операций INSERT, UPDATE и DELETE (IUD). Не забывай ОПТИМИЗАЦИЯ ТАБЛИЦЫ внутренние звонки ТАБЛИЦА АНАЛИЗА для обновления статистики строки индекса. Статистические данные строки индекса могут сильно сбрасываться в среде с тяжелым ВМС и могут помешать оптимизатору запросов MySQL сделать правильный выбор для планов запросов EXPLAIN. Если в таблице MyISAM происходит очень мало операций UPDATE и DELETE, OPTIMIZE TABLE не требуется. Если в таблице MyISAM нет DELETE, но много INSERT и UPDATE, ТАБЛИЦА OPTIMZIE очень экономно (раз в год) но бегать ТАБЛИЦА АНАЛИЗА в определенные периоды времени (возможно, раз в месяц).
Если мы говорим InnoDB, давайте поговорим о ваших настройках InnoDB. Если у вас есть innodb_file_per_table включен, то ОПТИМИЗАЦИЯ ТАБЛИЦЫ - все, ну и хорошо. Однако ANALYZE TABLE не влияет на InnoDB, поскольку статистика индексов вычисляется «на лету» путем погружений в индексы BTREE для аппроксимации мощности. Ожидайте, что файлы .ibd InnoDB будут расти быстрее, чем их аналоги MyISAM, потому что и данные, и страницы индекса находятся в одном файле .ibd, тогда как данные MyISAM и индекс находятся в отдельных файлах (.MYD и .MYI). Таким образом, InnoDB потребуются более частые операции OPTIMIZE TABLE, чем MyISAM.
Если у вас есть innodb_file_per_table отключен, вы должны изменить архитектуру инфраструктуры InnoDB прежде чем вы сможете успешно запустить ОПТИМИЗАЦИЯ ТАБЛИЦЫ команды для таблиц InnoDB.
Вы часто будете видеть, что производительность SSD, даже скорость чтения, ограничивается количеством операций ввода-вывода в секунду для вашего диска (ов). Возьми Intel X-25 E например - максимальная скорость чтения до 250 МБ / с, но также максимальная скорость чтения 35 000 операций в секунду, что приводит к максимальной скорости передачи 140 МБ / с для блоков размером 4 КБ.
Если известно, что ваши данные не являются смежными и ваши типичные операции чтения повлекут за собой загрузку последовательного ввода-вывода (т.е. вы увидите большие размеры запросов в нефрагментированной базе данных для вашей типичной нагрузки), производительность улучшится от запуска OPTIMIZE TABLE.
Безусловно, самый простой способ узнать, это просто проверить его - запустить команду OPTIMIZE TABLE для ваших наиболее часто используемых таблиц, получить типичную нагрузку на чтение / запись и проверить средний размер запроса (avgrq-sz), используя iostat -x /dev/<device>. Если avgrq-sz высокое (> 32 секторов), вы получили преимущество от ОПТИМИЗАЦИИ. Если нет, то, вероятно, не стоит беспокоиться в будущем, так как ваш шаблон доступа в любом случае довольно случайный.