Оптимизация оператора удаления MySQL
у меня есть некоторые запросы на удаление для выполнения против некоторой довольно огромной таблицы (~100 ГБ), и я хочу оптимизировать их как можно больше:
delete from table1 where column1 < date_sub(now(), interval 100 hour);
column1 является a datetime столбец, я предполагаю, что создание индекса для этого столбца ускорит удаления. помимо этого, что-нибудь я могу сделать здесь? будет использование date_sub() функция замедляет запрос? я должен вычислить то значение прежде, чем выполнить запрос?
delete from table2 where column2 = x;
column2 является первичным ключом для table2, таким образом, это уже - индекс согласно mysql документации. мой вопрос: индексный вид PRIMARY, тот же самый как INDEX? сделайте я должен сделать другой индекс вида INDEX для ускорения?
delete from table3 where column3 = y;
table3 имеет составной первичный ключ, который является column3 и column4. таким образом, у меня есть индекс первичного ключа, но так как запрос на удаление не использует column4, я должен сделать отдельный индекс только для column3? или объединенный первичный ключ сделал бы это?
я предполагаю, что это довольно основные вопросы, но я не мог найти определенный ответ характерным для моей ситуации, таким образом, любая справка будет цениться!
2 ответа
Если ваша DELETE предназначена для устранения подавляющего большинства строк в этой таблице, то часто люди копируют только те строки, которые вы хотите сохранить в дублирующую таблицу, а затем используют DROP TABLE или TRUNCATE, чтобы намного быстрее стереть исходную таблицу с лица земли.
Индекс может помочь найти строки, которые необходимо удалить, однако удаление требует обновления индекса. После удаления большого количества строк, индекс может быть несбалансированным и требует некоторого обслуживания с помощью OPTIMIZE TABLE.
Функция DATE_SUB() является константным выражением (она не меняется строками), поэтому оптимизатор запросов должен быть достаточно умным, чтобы рассчитать его и выполнить вычисление один раз.
Вам не нужно создавать дополнительный индекс для первичного ключа. Ограничение по первичному ключу неявно создает индекс, который дает те же преимущества, что и индекс не первичного ключа.
Составной индекс, вероятно, так же полезен, как и индекс, состоящий из одной колонки, при условии, что ваши критерии поиска ссылаются на самый левый столбец (столбцы) индекса. Оговорка "вероятно" связана с тем, что отдельные узлы индекса больше, и поэтому требуется больше памяти для кэширования индекса, но это достаточно маленький фактор, чтобы я не создал целый другой одноколоночный индекс
.предполагаю, что создание индекса для этого столбца ускорит удаление.
Неверно, потому что этот же индекс необходимо обновить, чтобы он имел любое значение для будущего использования.
замедлит ли запрос использование функции date_sub()?
Нет, все в порядке, потому что он не основан на значении столбца. Функции, выполняемые со значениями столбцов, гарантируют, что индекс, если он существовал на столбце, не может быть использован.
вид индекса - "PRIMARY", это то же самое, что и "INDEX"?
Это то же самое, и первичная часть гарантирует, что значения в этом индексе также уникальны.
Нужно ли мне делать другой индекс вида "INDEX" для ускорения?
Нет, не нужно. MySQL также ограничивает общий размер индексов, которые могут быть определены в одной таблице, в зависимости от типа. 767 байт - это объявленное ограничение префикса индекса для таблиц InnoDB; для таблиц MyISAM - 1000 байт.
table3 имеет составной первичный ключ - столбец3 и столбец4. поэтому у меня есть индекс первичного ключа, но так как запрос на удаление не использует столбец4, должен ли я сделать отдельный индекс только для столбца3, или комбинированный первичный ключ сделает это?
Проверьте обе установки и решите. Я сам не думаю, что дополнительный индекс нужен.