MySQL ALTER TABLE ORDER BY f1 DESC - блокирует ли этот запрос SELECT?

Question

У меня есть таблица MySQL MYISAM (скажем, tbl), состоящая из 2 беззнаковых целых полей, скажем, f1 и f2.На f2 есть индекс, и таблица очень большая (приблизительно 320 000 000+ строк).Я периодически обновляю эту таблицу (с примерно 100 000 новых строк в неделю), и, чтобы иметь возможность искать эту таблицу без выполнения ORDER BY (который будет очень трудоемким в запросах в реальном времени), я физически ЗАКАЗЫВАЮ таблицув соответствии с тем, как я хочу получить его строки.

Итак, я выполняю ALTER TABLE tBL ORDER BY f1 DESC.(Я знаю, что у меня достаточно физического пространства на сервере для копии таблицы.) Я прочитал, что во время этой операции создается временная таблица и операторы SELECT не влияют на текущие строки.

Однако я обнаружил, что это не так, и операторы SELECT в таблице, которые происходят одновременно с таблицей ALTER, блокируются и не завершаются.После завершения ALTER TABLE tbl (около 40 минут на производственном сервере) операторы SELECT на tbl снова начинают нормально работать.

Есть ли какая-то причина, по которой «ALTER table tbl ORDER BY f1 DESC» выглядитблокирование других клиентов от запроса tbl?

Answer 1

Изменение таблицы всегда захватывает блокировку таблицы, не позволяя запускать SELECT.

Я скажу, что даже не знаю, что вы могли бы сделать это с помощью ALTER TABLE.

Что вы пытаетесь получить со стола?Например, все записи в заданном диапазоне?320 миллионов строк - это не тривиальное число.Я расскажу вам о своих внутренних реакциях:

1. Переключиться на InnoDB (допускает # 2, также дает транзакции, но без # 2 может ухудшить производительность)
2. Разделение таблицы (делает этодействует как несколько таблиц немного меньшего размера)
3. Рассмотрим редизайн, такой как наличие таблицы «рабочего набора» и «исторической» таблицы, в основном разделение вручную.Если вы обычно ищете недавно вставленные данные, это (наряду с разделением) очень поможет.Если ваши поиски распределены равномерно, это, вероятно, не будет иметь значения.
4. Рассмотрите возможность добавления нового столбца, который вы можете использовать вместе, чтобы сузить выбор (поэтому вместо поиска по дате, поиска по дате и идентификатору клиента)

Поскольку я не знаю, что вы храните, некоторые из них (например, # 4) могут не применяться.

Есть некоторые другие вещи, которые вы можете попробовать.OPTIMIZE TABLE может помочь вам, но займет меньше времени, но я сомневаюсь в этом.Я думаю, что внутренне это реализовано как дамп / перезагрузка, по крайней мере на стороне InnoDB.