Mysql: створити індекс на 1,4 мільярда записів

У мене є таблиця з 1,4 мільярдами записів. Структура таблиці така:

CREATE TABLE text_page (
    text VARCHAR(255),
    page_id INT UNSIGNED
) ENGINE=MYISAM DEFAULT CHARSET=ascii

Вимога - створити індекс над стовпцем text.

Розмір столу - близько 34G.

Я спробував створити індекс за допомогою наступного твердження:

ALTER TABLE text_page ADD KEY ix_text (text)

Після 10-годинного очікування я нарешті відмовився від такого підходу.

Чи є якесь дієве рішення цієї проблеми?

ОНОВЛЕННЯ : таблиця навряд чи буде оновлена, вставлена ​​або видалена. Причина створення індексу на стовпці textполягає в тому, що такий запит sql часто виконується:

SELECT page_id FROM text_page WHERE text = ?

ОНОВЛЕННЯ : Я вирішив проблему, розділивши таблицю.

Таблиця розділена на 40 штук на стовпчик text. Потім створення індексу на столі займає близько 1 години.

Здається, що індекс MySQL стає дуже повільним, коли розмір таблиці стає дуже великим. А перегородка зменшує таблицю на менші стовбури.

Можливо, ваша система просто не вирішує завдання? Я не використовую MySQL (тут SQL Server), але я знаю, що індексує таблицю введення 800 мільйонів. В основному .... для цього вам потрібне відповідне обладнання (як у: багато швидких дисків). Зараз я використовую майже десяток Velociraptors і продуктивність чудова;)

Сервери SQL (не як MS SQL Server, а як сервери баз даних, що використовують SQL) живуть і гинуть з доступом до дисків, а звичайні диски просто не вирішують завдання великих операцій.

Ви можете створити індекс на перших (наприклад, 10) символах текстового поля.

З Документів:

Можна створити індекси, які використовують лише провідну частину значень стовпців, використовуючи синтаксис col_name (length) для визначення довжини префікса індексу:

CREATE INDEX ix_text ON text_page (text(10))

Я вирішив проблему, розділивши таблицю.

Таблиця розділена на 40 штук на стовпчик text. Потім створення індексу на столі займає близько 1 години.

Здається, що індекс MySQL стає дуже повільним, коли розмір таблиці стає дуже великим. А перегородка зменшує таблицю на менші стовбури.

Встановіть sort_buffer_size в 4 Гб (або скільки ви можете, залежно від обсягу пам'яті).

Зараз індекс створення робить щось на зразок, але оскільки у вас є 32MB sort_buffer_size, він в основному обробляє жорсткий диск без потреби.

Якщо вам не потрібно робити запити на зразок:

SELECT page_id FROM text_page WHERE text LIKE '?%';

Я б запропонував створити новий хеш-колонку та індексувати таблицю за стовпцем. Завищений розмір таблиці + індекс може бути значно меншим.

UPD : До речі, 1,4 мільярда цілих чисел первинного ключа займають близько 6 ГБ, тобто середня довжина рядка менше 30 символів, тобто індексація за префіксом може бути більш кращою.

Також слід поглянути на двигун зберігання даних MERGE .

Один із способів зробити це - створити нову таблицю з набором індексів і скопіювати дані в нову таблицю.

Крім того, переконайтеся, що у вас є достатньо місця на темп.

У випадку, якщо ви все ще цікавитеся, як це зробити найкраще, я б запропонував вам скористатись онлайн-інструментом для зміни таблиці.

В Інтернеті їх дуже багато, однією з відомих є:

• Змінення онлайн-схеми Percona (я використовую цю)
  http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html
• Facebook OSC, я не зміг знайти URL-адресу, де ви можете його завантажити

У нас такі ж проблеми з великими таблицями (більше 500 мільйонів записів), і зміна іде ідеально. Він створює нову таблицю tmp, додає тригер в оригінальну таблицю (для нового оновлення / видалення / вставки записів) і в середній час копіює всі записи в нову таблицю (з новою структурою)

Удачі!