|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день.
Имеестя таблица состоящая из 4-x столбцов
column_1
column_2
column_3
column_4
Создаем ключи
UNIQUE(column_1, column_2)
INDEX(column_3)
Делаем партиционирование по хешу от суммы уникального ключа
PARTITION BY HASH(column_1+column_2)
PARTITIONS 3
Получаем 6 файлов:
table#p0.MYD
table#p0.MYI
table#p1.MYD
table#p1.MYI
table#p2.MYD
table#p2.MYI
MYD - дата, MYI - индекс
Я так понял, что уникальный ключ будет храниться почастям в файлах table#p0.MYI, table#p1.MYI, table#p2.MYI
а при его использовании будут обрабатываться все три файла или только файл, удовлетворяющий
условию where
Помогите, пожалуйста, разобраться вот с каким вопросом:
1. Где будет храниться обычный ключ INDEX по полю column_3?
2. Что случиться если индекс окажется больше, чем объем оперативной памяти?
3. Партицирование VS партиционирование. Как правильно?
Неактивен
1. Там же, где и уникальный индекс — в файликах MYI. В нем будут только
те строки, которые попадают в раздел.
2. Будет подгружаться с диска по мере необходимости.
3. Правильно «разбиение» или «partitioning».
Неактивен
Спасибо. У меня возникла ошибка при создании индекса. Создаю индекс по 19 столбцам и получаю:
#1070 - Too many key parts specified; max 16 parts allowed
Нашел решение только здесь:
http://forums.mysql.com/read.php?35,102 … msg-159384
Необходимо увеличить MAX_REF_PARTS и MI_MAX_KEY_SEG, только где взять эти параметры?
Неактивен
Это параметры сборки, нужно взять исходники, заменить значения и перекомпилировать
сервер. Но, кажется, когда Вам нужно такое количество столбцов, можно пересмотреть
схему.
Неактивен
Дело в том, что баз будет большой(около 70ГБ) и я сделал партицирование по хешу суммы 4 столбцов, входящих в уникальный индекс.
Данные столбцы будут использоваться при каждом запросе. Остальные 15 будут испльзоваться редко.
Все 19 столбцов просто необходимы и будут выводиться при каждом запросе. Поэтому я и подумал о перекрывающем индексе, как о способе оптимизации.
Неактивен
