Нужно ли переиндексировать таблицу MySQL после массового удаления?

У меня есть таблица в MySQL с большим количеством INSERT и SELECT каждую секунду. И происходит массовое удаление некоторых старых данных один раз в день. Нужно ли переиндексировать таблицу после удаления? Я хочу увеличить производительность. Кто-нибудь может предложить несколько советов? Использование innodb в качестве механизма хранения. Я должен изменить это? Я думаю, что его лучше для одновременной вставки и выбора. Пожалуйста, дайте ваши предложения. Нужно ли делать переиндексацию?

Заранее спасибо..

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

Бесстыдная копия-вставка из документации MySQL :

Для таблиц InnoDB OPTIMIZE TABLE сопоставляется с ALTER TABLE, который перестраивает таблицу для обновления статистики индекса и освобождения неиспользуемого пространства в кластерном индексе. Это отображается в выводе OPTIMIZE TABLE при запуске его в таблице InnoDB, как показано здесь:

mysql> OPTIMIZE TABLE foo;
+----------+----------+----------+-------------------------------------------------------------------+
| Table    | Op       | Msg_type | Msg_text                                                          |
+----------+----------+----------+-------------------------------------------------------------------+
| test.foo | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.foo | optimize | status   | OK                                                                |
+----------+----------+----------+-------------------------------------------------------------------+

Эта операция не использует быстрое создание индекса. Вторичные индексы создаются не так эффективно, потому что ключи вставляются в том порядке, в котором они появились в первичном ключе. См. Раздел 14.14.6, «Ограничения быстрого создания индекса».

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

• Ожидается некоторый уровень фрагментации. InnoDB только заполняет страницы на 93%, чтобы оставить место для обновлений, не разбивая страницы.

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

• Обновления строк обычно перезаписывают данные на одной странице, в зависимости от типа данных и формата строки, когда доступно достаточно места. См. Раздел 14.10.5, «Как работает сжатие для таблиц InnoDB» и Раздел 14.12.1, «Обзор хранения строк InnoDB».

• Рабочие нагрузки с высокой степенью параллелизма могут со временем оставлять пробелы в индексах, поскольку InnoDB сохраняет несколько версий одних и тех же данных благодаря своему механизму MVCC. См. Раздел 14.5.12, «Многовариантность InnoDB».

Вы можете переиндексировать таблицу и даже сжать таблицу. Однако, если вы хотите отложить такое обслуживание на диске, вам следует, как минимум, пересчитать статистику индекса.

Без пересчета статистики индекса MySQL Query Optimizer может сделать неправильный выбор для планов запроса EXPLAIN. Это может отрицательно повлиять на SELECT, если статистика по несуществующим данным все еще присутствует. Это верно как для MyISAM, так и для InnoDB.

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

Чтобы вычислить статистику для всех индексов в таблице, вы должны запустить

ANALYZE TABLE tablename;

Вы могли бы делать это каждую ночь. Он не будет пытаться выполнять дефрагментацию или сжатие данных. Вы могли бы сделать это один раз в неделю, запустив OPTIMIZE TABLE tablename;. Это также будет делать ANALYZE TABLE tablename;для вас после сжатия физического файла таблицы ( .ibdдля InnoDB или .MYIдля MyISAM) или.

OPTIMIZE TABLE почти никогда не требуется в InnoDB.

Вы удаляете записи по возрасту? Если это так, вы можете сделать массовое удаление практически свободным, используя PARTITIONing и DROP PARTITION. Более подробная информация здесь: http://mysql.rjweb.org/doc.php/partitionmaint