UNIX_TIMESTAMP полевой раздел на целый год

Question

UNIX_TIMESTAMP полевой раздел на целый год

0

Я совершенно новый в теме разделов, и необходимость возникла из-за большого накопления данных.

Ну, в основном это система контроля доступа, в настоящее время существует 20 отделов, и каждый отдел насчитывает около 100 пользователей. Система записывает дату и время записей и выходов (from_date/to_date). Мое намерение состоит в разделении по отделам, а затем в течение месяца в течение года.

План:
Разделите таблицу на [ dep_id и date (from_date и to_date)]

проблема
У меня есть следующая таблица.

CREATE TABLE 'employee' (
  'employee_id' smallint(5) NOT NULL,
  'dep_id' int(11) NOT NULL,
  'from_date' int(11) NOT NULL,
  'to_date' int(11) NOT NULL,
  KEY 'index1' ('employee_id','from_date','to_date')
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

У меня есть даты (from_date и to_date) в формате UNIX_TIMESTAMP (INT 11). Я хочу разделить его в течение всех месяцев года. Возможно?

Mysql - 5,7

Chap2 30 май 2018, в 04:54

Источник

0

Теоретически, можно создать разделы, а затем подразделы в каждом разделе (разделы должны быть идентичны в каждом разделе.) На практике подразделы - плохая идея. Я не сталкивался со случаем использования, когда разбиение было подходящим. Но, возможно, ваш случай использования - одна из редких птиц. Вы показали нам план, но без обоснования этого плана, поэтому я не могу с чистой совестью представить предложение относительно подразделов, отличных от «не делай этого».
spencer7593 30 май 2018, в 02:52
0

Спасибо @spencer7593 spencer7593 Ну, в основном это система контроля доступа, в настоящее время в ней 20 отделов, и в каждом из них около 100 пользователей. Система записывает дату и время входа и выхода (from_date / to_date). Мое намерение состоит в том, чтобы разделить по отделам, а затем на месяц в течение года
Chap2 30 май 2018, в 02:59
1

таким образом, 20 x 100 = 2000 пользователей, при условии 100 входов / выходов в день на пользователя, то есть 200 000 в день. Раз 30 дней в месяц, это 6 000 000 строк в месяц. (Я просто приблизился к числам, вы можете сделать математику.) Если план состоит в том, чтобы «устаревать» более старые данные, то разбиение диапазона по месяцам даст вам возможность вернуть пространство назад, когда старые разделы будут удалены , Если это план, я бы оставил его простым и не связывался с двумя уровнями разбиения.
spencer7593 30 май 2018, в 03:38

Показать ещё 1 комментарий

Теги:

mysql

sql

1 ответ

Ещё вопросы

Теоретически, можно создать разделы, а затем подразделы в каждом разделе (разделы должны быть идентичны в каждом разделе.) На практике подразделы - плохая идея. Я не сталкивался со случаем использования, когда разбиение было подходящим. Но, возможно, ваш случай использования - одна из редких птиц. Вы показали нам план, но без обоснования этого плана, поэтому я не могу с чистой совестью представить предложение относительно подразделов, отличных от «не делай этого».
Спасибо @spencer7593 spencer7593 Ну, в основном это система контроля доступа, в настоящее время в ней 20 отделов, и в каждом из них около 100 пользователей. Система записывает дату и время входа и выхода (from_date / to_date). Мое намерение состоит в том, чтобы разделить по отделам, а затем на месяц в течение года
таким образом, 20 x 100 = 2000 пользователей, при условии 100 входов / выходов в день на пользователя, то есть 200 000 в день. Раз 30 дней в месяц, это 6 000 000 строк в месяц. (Я просто приблизился к числам, вы можете сделать математику.) Если план состоит в том, чтобы «устаревать» более старые данные, то разбиение диапазона по месяцам даст вам возможность вернуть пространство назад, когда старые разделы будут удалены , Если это план, я бы оставил его простым и не связывался с двумя уровнями разбиения.

spencer7593 · Answer 1 · 2018-05-30T02-26-00.000Z

Можно использовать разбиение диапазонов на целочисленный столбец.

Предполагая, что my_int_col является целым числом в стиле unix с 1970-01-01

мы могли бы достичь ежемесячных разделов с чем-то вроде этого:

PARTITION BY RANGE (my_int_col)
( PARTITION p20180101 VALUES LESS THAN ( UNIX_TIMESTAMP('2018-01-01 00:00') )
, PARTITION p20180201 VALUES LESS THAN ( UNIX_TIMESTAMP('2018-02-01 00:00') )
, PARTITION p20180301 VALUES LESS THAN ( UNIX_TIMESTAMP('2018-03-01 00:00') )
, PARTITION p20180401 VALUES LESS THAN ( UNIX_TIMESTAMP('2018-04-01 00:00') )
, PARTITION p20180501 VALUES LESS THAN ( UNIX_TIMESTAMP('2018-05-01 00:00') )
, PARTITION p20180601 VALUES LESS THAN ( UNIX_TIMESTAMP('2018-06-01 00:00') )

Будьте осторожны с настройкой time_zone сеанса. Эти литераторы даты будут интерпретироваться как значения в текущем time_zone... например, если вы хотите, чтобы они были датами UTC, time_zone должен быть +00: 00.

Или замените выражение UNIX_TIMESTAMP() на значение буквального целого... что MySQL будет делать с выражениями UNIX_TIMESTAMP().

Очевидно, вы можете назвать разделы, что хотите.

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

Можно создать новую таблицу, которая будет разбита на разделы, а затем скопировать старые данные на кусок за раз. Но сделайте куски разумно рассчитанными, чтобы избежать взлета ibdata1 с большими транзакциями. Затем выполните некоторые инструкции RENAME TABLE, чтобы переместить старую таблицу и переместите новую таблицу.

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

Стратегические индексы и тщательно спланированные запросы являются ключом к производительности с "очень большими" таблицами. И это верно и для секционированных таблиц.

Разделение - это не волшебная пуля для проблем с производительностью, которые некоторым новичкам это хотелось бы.

Что касается создания дочерних разделов внутри разделов, я бы не рекомендовал его.

Спасибо @ spencer7593, я приму к сведению ваши рекомендации.
Существуют и другие схемы разбиения, отличные от RANGE. Например, если в таблицу включен целочисленный столбец, представляющий год и месяц (все строки в одном и том же месяце имеют одинаковое значение для этого столбца), то мы могли бы реализовать, например, разбиение LIST.