2016-08-01 3 views
0

Это для MySQL 5.7 с InnoDB.MySQL - Загрузка данных по разделам и индексам

У меня есть секционированная таблица, и я буду выполнять загрузку пакетных данных (большого количества данных) по разделам. т. е. я знаю, что каждая партия загружаемых данных будет попадать исключительно в один раздел.

Теперь, общий способ обработки индексов с загрузкой данных (насколько я знаю), заключается в том, чтобы сначала удалить все индексы, выполнить загрузку данных, а затем воссоздать индексы.

Но мне интересно, поскольку я загружаю разделы, это самый оптимальный способ (отбрасывание и повторное создание индексов), поскольку кажется, что я неоправданно «касаюсь» не обновленных разделов сюда.

например.

  1. Загрузка данных в раздел 1.
    1. Отбросьте все индексы - ничего не происходит, так как нет данных пока нет.
    2. Загрузить данные - все переходит в раздел 1.
    3. Создание индексов - изменено только поле 1.
  2. Загрузка данных в раздел 2.
    1. Отбросьте все индексы - все индексы в разделе 1 отброшено (ненужное!)
    2. нагрузки данных - все переходит в раздел 2.
    3. Создание индексов - раздел Созданы 1 индексы (ненужные!) И индексы раздела 2.
    4. И, следовательно, загрузка этой второй партии данных занимает значительно больше времени, чем первая партия. И это будет хуже для каждой партии!

В этом случае, я должен просто предварительно создать индексы и оставить их там при загрузке данных?

(кстати, не беспокойтесь о запросах. База данных «отсутствует», когда загрузка данных происходит. Цель здесь только сократить время для каждой партии загрузки данных.)

Схема таблицы выглядит следующим образом:

CREATE TABLE MYTABLE (
    ID  BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, 
    YEAR SMALLINT UNSIGNED NOT NULL, 
    MONTH TINYINT UNSIGNED NOT NULL, 
    A  CHAR(4), 
    B  VARCHAR(127), 
    C  VARCHAR(15), 
    D  VARCHAR(511), 
    E  TEXT, 
    F  TEXT, 
    G  VARCHAR(127), 
    H  VARCHAR(127), 
    I  VARCHAR(127), 
    J  VARCHAR(511), 
    K  VARCHAR(511), 
    L  BIT(1), 
    CONSTRAINT PKEY PRIMARY KEY (ID, YEAR, MONTH) 
) 
PARTITION BY LIST COLUMNS(YEAR, MONTH) (
    PARTITION PART1 VALUES IN ((2007, 1)), 
    PARTITION PART2 VALUES IN ((2007, 2)), 
    PARTITION PART3 VALUES IN ((2007, 3)), 
    ... 
); 

И, конечно же, есть куча указателей (14 во всех), в основном с участием от 2 до 4 столбцов. Ни один из столбцов 2 TEXT ни в одном из индексов.

+0

InnoDB? Что такое «ВЫБОРЫ»?Какие индексы вы будете добавлять? utf8? Действительно ли выгодно разделять 'YEAR' и' MONTH' вместо использования одного столбца 'DATE'? Будет ли выбор длиться более одного месяца? Вы всегда используете 'WHERE year = constant AND month = constant'? –

ответ

2

Если вы используете InnoDB, не роняйте PRIMARY KEY.

Все PARTITIONs всегда имеют одинаковые индексы. Таким образом, вы не можете включать и выключать индексы отдельно.

Просьба предоставить SHOW CREATE TABLE для дальнейшей критики и совета. I может сказать, что PARTITIONing бесполезен; существует очень мало случаев использования, было целесообразно использовать PARTITION. More info, and use cases

+0

Для этой таблицы у меня есть данные, основанные на времени. Каждая партия представляет собой месяц данных. Разделение поможет справиться со старением данных (например, удаление всего раздела, когда некоторые старые данные больше не используются). Поймите, что я не могу иметь индекс по отдельному разделу. Отсюда вопрос. Вместо того, чтобы отбрасывать и воссоздавать индекс каждый раз, когда я загружаю пакет данных, было бы лучше оставить там индекс, так что всякий раз, когда я загружаю данные, другие разделы не нужно «трогать», если вы сбросите и создадите индекс без необходимости? –

+0

О, я не отбрасываю ПЕРВИЧНЫЙ КЛЮЧ ... только индексы, отличные от ПК. –

+0

Я понимаю вопрос, но у меня нет прямого ответа. Я бы хотел увидеть индексы в любом случае. Этот случай использования очень хорош. Другой вопрос: Сколько строк в «партии»? –