Jak długo powinno zająć zbudowanie indeksu przy użyciu ALTER TABLE w MySQL?

To może być trochę jak pytanie o długość ciągu, ale statystyki są następujące:

  • Dwurdzeniowy procesor Intel 4 GB pamięci RAM
  • Tabela z 8 milionami wierszy, ~ 20 kolumn, głównie varchary z głównym identyfikatorem auto_increment
  • Zapytanie to: ALTER TABLE moja_tabela ADD INDEX my_index (moja_kolumna);
  • moja_kolumna to varchar(200)
  • Pamięć to MyISAM

Rząd wielkości, czy powinien to być 1 minuta, 10 minut, 100 minut?

Dziękuję

Edytuj: OK, zajęło to 2 godziny 37 minut, w porównaniu do 0 godzin 33 minut na maszynie o mniejszej specyfikacji przy zasadniczo identycznych konfiguracjach. Nie mam pojęcia, dlaczego trwało to tak długo. Jedyną możliwością jest to, że maszyna prodowa HD jest pełna w 85%, przy 100 GB wolnego miejsca. Powinno wystarczyć, ale myślę, że zależy to od tego, jak dystrybuowana jest wolna przestrzeń.


person Richard H    schedule 15.02.2010    source źródło
comment
Jak długo to trwa w środowisku testowym? Obciążenie serwera byłoby jedyną rzeczą, której nie można było uwzględnić, ale nie widziałem, aby trwało to dłużej niż minutę.   -  person OMG Ponies    schedule 15.02.2010
comment
po prostu działam teraz w środowisku deweloperskim. Spodziewałem się około 5 minut. 30 minut później nic jeszcze nie zostało zrobione. Dodatkowo na górze mysqld wydaje się bardzo nieaktywny, podczas gdy w dev widzę 60% + procesora   -  person Richard H    schedule 15.02.2010
comment
Sprawdź, czy nie zabrakło Ci miejsca na dysku, w szczególności w katalogu tymczasowym mysql.   -  person nos    schedule 15.02.2010


Odpowiedzi (3)


Jeśli dodajesz tylko pojedynczy indeks, powinno to zająć około 10 minut. Jednak zajmie to 100 minut lub więcej, jeśli nie masz tego pliku indeksu w pamięci.

Twój 200 varchar z 8 milionami wierszy zajmie maksymalnie 1,6 GB, ale przy całym nakładzie indeksowania zajmie około 2-3 GB. Ale zajmie to mniej, jeśli większość wierszy ma mniej niż 200 znaków. (Możesz wybrać sum(length(my_column)), aby sprawdzić, ile miejsca jest wymagane).

Chcesz edytować swój /etc/mysql/my.cnf plik. Graj z tymi ustawieniami;

myisam_sort_buffer_size = 100M
sort_buffer_size = 100M

Powodzenia.

person vy32    schedule 15.02.2010
comment
Cześć, dzięki za to. Zrobiłem to wcześniej z rzędami ~4mm i zakończyło się to dość szybko, więc tak z 8mm może prawdopodobnie wepchnąłem indeks na dysk. - person Richard H; 15.02.2010

W mojej testowej bazie danych MusicBrainz tabela track buduje PRIMARY KEY i trzy indeksy pomocnicze w 25 minut:

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

Tabela zawiera 9001870 rekordów.

Maszyna to Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz z 2Gb RAM, Fedora Core 12, MySQL 5.1.42.

@@myisam_sort_buffer_size is 256M.

person Quassnoi    schedule 15.02.2010
comment
hmm, wygląda na to, że myisam_sort_buffer_size lub sort_buffer_size nie są określone w moim pliku my.cnf... - person Richard H; 15.02.2010
comment
ok, więc jest skończony w moim środowisku testowym, które ma niższą specyfikację (3 GB, nieco wolniejszy procesor) w 33 minuty. Prod wciąż się kręci. chciałbym, żeby była aktualizacja statusu czy coś .... - person Richard H; 15.02.2010
comment
@Richard: jeśli nie jest określony, ma wartość domyślną (8M). Możesz to sprawdzić, wydając SELECT @@myisam_sort_buffer_size. Ta wartość jest zdecydowanie za niska, powinieneś ją zwiększyć (zwłaszcza jeśli masz 3 Gb z RAM). Ta pamięć jest używana (i przydzielana) tylko podczas tworzenia lub naprawiania indeksów, więc można ją zwiększyć. @@sort_buffer_size nie wpływa na szybkość tworzenia indeksu, dotyczy tylko zapytań. - person Quassnoi; 16.02.2010

Dodatkowo, jeśli kiedykolwiek będziesz musiał zbudować wiele indeksów, najlepiej jest utworzyć wszystkie indeksy w jednym wywołaniu, a nie pojedynczo... Powód: w zasadzie wydaje się, że należy przepisać wszystkie strony indeksu, aby zawierały nowy indeks z tym, co miał. Dowiedziałem się o tym w przeszłości, mając tabelę 2+ gigabajtów i musiałem zbudować na niej około 15 indeksów. Budowanie wszystkich indywidualnie utrzymywane przyrostowo rośnie w czasie pomiędzy każdym indeksem. Następnie próbowanie wszystkich naraz wymagało nieco więcej niż około 3 pojedynczych indeksów, ponieważ zbudowano wszystkie na rekord i zapisano wszystko naraz, zamiast ciągle odbudowywać strony.

person DRapp    schedule 15.02.2010