Сколько времени нужно, чтобы построить индекс с помощью ALTER TABLE в MySQL?

Это может быть немного похоже на вопрос о длине строки, но статистика такова:

  • Двухъядерный Intel 4 ГБ оперативной памяти
  • Таблица с 8 миллионами строк, ~ 20 столбцов, в основном varchars с первичным идентификатором auto_increment
  • Запрос: ALTER TABLE my_table ADD INDEX my_index (my_column);
  • my_column - это varchar (200)
  • Хранилище MyISAM

Порядок величины должен быть 1 минута, 10 минут, 100 минут?

Спасибо

Редактировать: Хорошо, это заняло 2 часа 37 минут по сравнению с 0 часами 33 минутами на машине с меньшими характеристиками, с практически идентичными настройками. Я понятия не имею, почему это заняло так много времени. Единственная возможность состоит в том, что рабочая машина HD заполнена на 85%, а 100 ГБ свободно. Должно быть достаточно, но я думаю, это зависит от того, как распределяется это свободное пространство.


mysql indexing
person Richard H    schedule 15.02.2010    source источник
comment
Сколько времени это занимает в тестовой среде? Нагрузка на сервер была бы единственным, что вы не могли учесть, но я не мог предположить, что это займет больше минуты.   -  person OMG Ponies    schedule 15.02.2010
comment
сейчас я просто работаю в среде разработчиков. Я ожидал около 5 минут. 30 минут спустя еще ничего не сделано. Кроме того, в верхней части mysqld выглядит очень неактивным, в то время как в dev я вижу 60% + процессор.   -  person Richard H    schedule 15.02.2010
comment
Проверьте, не закончилось ли у вас место на диске, в частности, во временном каталоге mysql.   -  person nos    schedule 15.02.2010

Ответы (3)


arrow_upward
8
arrow_downward

Если вы просто добавляете один индекс, это займет около 10 минут. Однако это займет 100 минут или больше, если у вас нет этого индексного файла в памяти.

Ваши 200 varchar с 8 миллионами строк займут максимум 1,6 ГБ, но со всеми накладными расходами на индексацию это займет около 2-3 ГБ. Но это займет меньше, если большинство строк меньше 200 символов. (Возможно, вы захотите сделать выбор sum(length(my_column)), чтобы узнать, сколько места требуется.)

Вы хотите отредактировать файл /etc/mysql/my.cnf. Поиграйте с этими настройками;

myisam_sort_buffer_size = 100M
sort_buffer_size = 100M

Удачи.

person vy32    schedule 15.02.2010
comment
Привет, спасибо за это. Я делал это раньше со строками ~ 4 мм, и это было выполнено довольно быстро, так что да, с 8 мм, возможно, я, вероятно, вставил индекс на диск. - person Richard H; 15.02.2010

arrow_upward
2
arrow_downward

В моей тестовой базе данных MusicBrainz таблица track создает PRIMARY KEY и три вторичных индекса за 25 минут:

CREATE TABLE `track` (
  `id` int(11) NOT NULL,
  `artist` int(11) NOT NULL,
  `name` varchar(255) NOT NULL,
  `gid` char(36) NOT NULL,
  `length` int(11) DEFAULT '0',
  `year` int(11) DEFAULT '0',
  `modpending` int(11) DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `gid` (`gid`),
  KEY `artist` (`artist`),
  KEY `name` (`name`)
) DEFAULT CHARSET=utf8

В таблице 9001870 записей.

Машина Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz с 2Gb RAM, Fedora Core 12, MySQL 5.1.42.

@@myisam_sort_buffer_size is 256M.

person Quassnoi    schedule 15.02.2010
comment
хм, кажется, у меня нет myisam_sort_buffer_size или sort_buffer_size, указанных в моем my.cnf... - person Richard H; 15.02.2010
comment
хорошо, так что это завершено в моей тестовой среде, которая имеет более низкую спецификацию (3 ГБ, немного более медленный процессор) за 33 минуты. Prod все еще работает. я бы хотел, чтобы было обновление статуса или что-то в этом роде.... - person Richard H; 15.02.2010
comment
@Richard: если он не указан, то он имеет значение по умолчанию (8M). Вы можете проверить это, выдав SELECT @@myisam_sort_buffer_size. Это значение слишком низкое, его следует увеличить (особенно если у вас 3 Gb из RAM). Эта память используется (и выделяется) только при создании или восстановлении индексов, поэтому ее можно увеличить. @@sort_buffer_size не влияет на скорость создания индекса, влияет только на запросы. - person Quassnoi; 16.02.2010

arrow_upward
1
arrow_downward

Кроме того, если вам когда-нибудь понадобится создать несколько индексов, лучше всего создавать все индексы за один вызов, а не по отдельности... Причина: в основном кажется, что нужно переписать все страницы индекса, чтобы они включали ваш новый индекс с тем, что у него было. Я узнал об этом в прошлом, имея таблицу размером более 2 гигов, и мне нужно было построить на ней около 15 индексов. Построение всех по отдельности продолжало постепенно увеличиваться во времени между каждым индексом. Тогда попытка все сразу была чуть больше, чем около 3 отдельных индексов, поскольку он строил все для каждой записи и записывал все сразу, вместо того, чтобы продолжать перестраивать страницы.

person DRapp    schedule 15.02.2010