Индексы в mysql

[detected]

В таблице 3 столбца, строк около 400к
Нашел не индексированный столбец, выполнил запрос
ALTER TABLE `section` ADD INDEX(`element_id`);
И все, сайт и мускул лежит уже часа 5-6 с 504, он всегда так долго выполняется? И что делать, подскажите новичку пожалуйста(

[zelenin]

вообще долговато для 400к, но в принципе может быть. жди утра)

[rugabarbo]

1. Это InnoDB или MyISAM?
2. Какая версия MySQL?

[rugabarbo]

^ отредактировал свой ответ, потому что дока показала, что в новых версиях MySQL дело может обстоять иначе...

[detected]

Версия сервера: 5.5.58-0+deb8u1 - (Debian)
Apache/2.4.10 (Debian) mod_fcgid/2.3.9 OpenSSL/1.0.1t
Версия клиента базы данных: libmysql - 5.5.58
Информация о версии: 4.2.12deb2+deb8u2
InnoDB
Включаются только те страницы, которые не работают с данной таблицей

[rugabarbo]

По идее должны работать страницы, которые читают эту таблицу, потому что она залочена на запись.
Столбец `section`.`element_id` типа INT?

[detected]

int все

[detected]

Написал сисадмину, он поднял его. На вопрос в чем была проблема - зависшие запросы, как это понимать? Что мне теперь, никак не добавить индексы на столбец

[rugabarbo]

Зайдите в консоль мускуля и сделайте:

Код: Выделить всё

select @@tmpdir;

Результат сюда скиньте.

[rugabarbo]

А потом нам дайте ещё результат работы команды:

Код: Выделить всё

df -h

Это в консоли сервера.

[rugabarbo]

Объясню, зачем нужны эти данные.

В MySQL 5.5 secondary-индексы для InnoDB должны создаваться относительно быстро за счёт InnoDB Fast Index Creation. То есть никакого копирования таблицы проихсодить не должно.

При этом данных в колонке у вас мало. 400 000 значений типа INT по 8 байт – это 3-4 Мб от силы. Соответственно, индекс для такого объёма данных должен выстраиваться достаточно быстро.

А значит, есть вероятность, что упёрлись в какие-то ограничения быстрого создания индексов. Наиболее вероятна какая-то проблема с tmpdir – например, там нет места, и мускуль ждёт его освобождения во время построения индекса. Всё виснет.