Форум пользователей MySQL

Все эти четыре разбиения достаточно похожи друг на друга, это факт. Для того, чтобы понять,
как оно будет разбиваться, нужно оторваться от значений слов HASH и KEY в том понимании,
как они используются обычно.

1. Начнем с HASH. Hash нужно в данном случае понимать не как привычный нам хэш (типа md5),
а как математическую функцию, которая берет число на входе и получает какое-то другое число
на выходе. Самый примитивный способ — на выходе то же самое число, что и на входе. Выбор
раздела при этом происходит путем вычисления остатка от деления этого числа на количество
разделов. Звучит несколько запутанно, поэтому пример.

Вставляем строки в таблицу из двух разделов с хэш-разбиением. Вставляем строку 1. Остаток
от деления 1 на 2 — 1, поэтому строка попадает в 1 раздел. Вторая строка — по аналогии, во второй.
Третья — опять в первый (3 % 2 = 1). Четвертая — во второй. И так далее.
Т.е. при равномерном увеличении числа на 1 мы получаем, что строки равномерно попадают в два
раздела. Если числа будут увеличиваться другим способом — разбиение может быть менее
качественным (например, 1,3,5,.. — будут попадать всегда в один раздел).

В HASH можно использовать какие-то выражения (до взятия остатка от деления). Например, если
у Вас в таблице хранятся числа от 0 до 1, и Вы хотите разбивать таблицу на 2 раздела, то можно взять
хэширующую функцию field * 2 (или field * 100), тогда при округлении до целого числа (для вычисления
модуля) MySQL будет получать не только ноль, но и другие числа.

2. LINEAR HASH. Наверное, не очень удачное название, но уж как есть. Отличие от обычного хэша в том,
что вычисление номера раздела по числу хэш-функции — не взятие модуля, а более сложный алгоритм:
F() & (POWER(2, CEILING(LOG(2, num))) - 1).
Насколько удачно такое решение — не известно, но утверждается, что в таком случае гораздо проще
добавлять-удалять разделы (т.к. используются степени двойки, обычно делится только один из разделов).
С другой стороны, теряется равномерность.

3. KEY. Если все понятно с HASH, то с KEY все еще проще — тут искусственно навязывается встроенный
алгоритм хэширования. Сделано это для того, чтобы можно было разбивать таблицу не только по числовому
полю, но, например, по строковому. На алгоритм никак повлиять нельзя, он всегда фиксированный.

4. LINEAR KEY. Аналогично пунктам 2 и 3 — фиксированный алгоритм хэширования + выбор раздела не остатком
от деления, а линейным двоичным алгоритмом.

--

Что касается «ускорения поиска». Единственный способ ускорить поиск разбиением — не читать не
затрагиваемые разделы. PRUNING будет работать на этих видах разбиения только в случае точечных
запросов с WHERE по указанному полю (например, WHERE field = 1). В любых других случаях, MySQL
не сможет оценить, какие разделы будут затронуты, и прийдется обработать все из них.

Да, разумеется. Главное, чтобы было понятно, из какого раздела тянуть, на этапе работы
оптимизатора. Т.к. оптимизатор может посчитать KEY('JOHN'), он может определить, из какого
раздела вытянуть данные. Как следствие, будет читаться только этот раздел.

Хорошего способа нет, но, например, если Вы используете MyISAM, можете
попробовать такой трюк:
  1. Сделать резервную копию, которую будете уносить (mysqlhotcopy)
  2. Очистить раздел (TRUNCATE PARTITION)
При этом раздел у Вас останется, просто он будет пустым. Когда нужно бу-
дет восстановить раздел — нужно будет:
  1. Заблокировать табличку (LOCK TABLES .. WRITE);
  2. Сбросить кэши на диск (FLUSH TABLES ..);
  3. Перезаписать файлы восстанавливаемого раздела;
  4. Разблокировать табличку (UNLOCK TABLES);
Этапы 1 и 4 должны выполняться отдельным соединением, которое должно
держать блокировку в процессе работы (т.е. выполнить 1 и закрыть клиент
нельзя).

Ну и потренируйтесь на небоевых данных сначала, конечно.

PARTITIONS 8 означает, что таблица будет разбита на 8 разделов. Данные будут разнесены по значению ключа region_code по принципу "на первый - восьмой рассчитась!".

Во втором случае будет два раздела, у обоих указан механизм хранения Innodb. MySQL хранит разделы как отдельные таблицы, поэтому в принципе они могут иметь и разный механизм хранения (в MySQL 5.5 если указать у второго раздела Engine=MyISAM, будет ошибка "ERROR 1497 (HY000): The mix of handlers in the partitions is not allowed in this version of MySQL" )

Vitas написал:

Тогда вопрос как выбрать оптимальное значение этого параметра? На чем основываться при выборе?

основываться на тестах производительности

Vitas написал:

Данный синтаксис идентичен комманде "PARTITIONS 2"?
Или это реально 2 таблицы, а не 2 части одной таблицы?

эквивалентно PARTITIONS 2. Физически (на уровне хранилища) разделы в любом случае хранятся как если бы это были отдельные таблицы, но обращение к ним как к одной таблице.