MySQL ALTER TABLE на очень большой таблице - безопасно ли ее запускать?

Question

У меня есть база данных MySQL с таблицей MyISAM с 4 миллионами строк. Я обновляю эту таблицу примерно раз в неделю, добавляя около 2000 новых строк. После обновления я затем изменяю таблицу следующим образом:

ALTER TABLE x ORDER BY PK DESC

Я упорядочиваю таблицу по полю первичного ключа в порядке убывания. Это не доставило мне никаких проблем на моей машине для разработки (Windows с 3 ГБ памяти). Трижды я успешно пробовал его на рабочем сервере Linux (с 512 МБ ОЗУ - и получал в результате отсортированную таблицу примерно за 6 минут каждый раз), в последний раз я пытался остановить запрос через 30 минут и перестроить база данных из резервной копии.

Может ли сервер 512 МБ справиться с этим оператором alter для такой большой таблицы? Я прочитал, что временная таблица создается для выполнения команды ALTER TABLE.

Вопрос: Можно ли безопасно выполнить эту команду alter? Какое должно быть ожидаемое время для изменения таблицы?

Answer 1

Как я только что прочитал, запрос ALTER TABLE ... ORDER BY ... полезен для повышения производительности в определенных сценариях. Я удивлен, что PK Index не помогает с этим. Но из документов MySQL кажется, что InnoDB использует индекс. Однако InnoDB имеет тенденцию быть медленнее, чем MyISAM. Тем не менее, с InnoDB вам не нужно будет переупорядочивать стол, но вы потеряете невероятную скорость MyISAM. Это все еще может стоить выстрел.

То, как вы объясняете проблемы, кажется, что в память загружено слишком много данных (может быть, даже происходит обмен?). Вы можете легко проверить это с помощью мониторинга использования памяти. Трудно сказать, поскольку я не очень хорошо знаю MySQL.

С другой стороны, я думаю, что ваша проблема лежит в другом месте: вы используете компьютер с 512 мегабайтами ОЗУ в качестве сервера базы данных с таблицей, содержащей более 4 миллионов строк ... И вы выполняете очень Операция с большим объемом памяти на всей таблице на этой машине. Кажется, что 512Megs почти не хватит для этого.

Здесь я вижу гораздо более фундаментальную проблему: вы занимаетесь разработкой (и, скорее всего, также тестированием) в среде, которая сильно отличается от производственной среды. Вид проблемы, которую вы объясняете, следует ожидать. Ваша машина для разработки имеет в шесть раз больше памяти, чем ваша рабочая машина. Я уверен, что могу с уверенностью сказать, что процессор гораздо быстрее. В этом случае я предлагаю вам создать виртуальную машину, имитирующую ваш производственный сайт. Таким образом, вы можете легко протестировать свой проект, не нарушая производственную площадку.

Answer 2

это первичный ключ auto_increment? если это так, то выполнение команды ALTER TABLE ... ORDER BY не улучшит ничего, так как все равно будет вставлено по порядку.

(если у вас нет большого количества удалений)

Answer 3

Если вы используете InnoDB, вам не нужно явно выполнять ORDER BY либо после вставки, либо во время запроса. Согласно руководству по MySQL 5.0, InnoDB уже по умолчанию использует порядок первичного ключа для результатов запроса:

http://dev.mysql.com/doc/refman/5.0/en/alter-table.html#id4052480

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

Answer 4

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

Я подвергаю сомнению ваше мнение при выборе машины с таким крошечным объемом памяти. В любом случае:

• Действительно ли необходим этот ALTER TABLE; какой конкретный запрос вы пытаетесь ускорить, и без него вы пробовали?
• Рассматривали ли вы сделать свою машину для разработки более похожей на производство? Я имею в виду, что использование dev-бокса с БОЛЬШЕЙ памятью никогда не было бы хорошей идеей, и использование другой ОС определенно также не подходит.

Возможно, вы также можете выполнить некоторые настройки, чтобы попытаться помочь; это в значительной степени зависит от вашей схемы (в частности, от индексов). 4М рядов не очень много (для машины с нормальным количеством оперативной памяти).

Answer 5

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