MySQL раздел на категориальных полях и метка времени столбца, который является VARCHAR - PullRequest
Новая
       23

MySQL раздел на категориальных полях и метка времени столбца, который является VARCHAR

0 голосов
/ 25 января 2019

В настоящее время у нас есть таблица: 

CREATE TABLE `T_TRANS` (
  `CASE_ID` varchar(20) DEFAULT NULL,
  `C_ID` varchar(20) DEFAULT NULL,
  `C_ST_IND` smallint(6) DEFAULT NULL,
  `D_DTTM` int(11) DEFAULT NULL,
  `E_ID` varchar(10) DEFAULT NULL,
  `E_LONG` decimal(11,7) DEFAULT NULL,
  `E_LAT` decimal(9,7) DEFAULT NULL,
  `EV_IND` smallint(6) DEFAULT NULL,
  `H_B_IND` smallint(6) DEFAULT NULL,
  `V_IND` varchar(15) DEFAULT NULL,
  `I_IND` smallint(6) DEFAULT NULL,
  `I_P_IND` smallint(6) DEFAULT NULL,
  `I_S_IND` smallint(6) DEFAULT NULL,
  `IS_D_IND` smallint(6) DEFAULT NULL,
  `IS_R_IND` smallint(6) DEFAULT NULL,
  `L_IND` smallint(6) DEFAULT NULL,
  `D_LONG` decimal(11,7) DEFAULT NULL,
  `D_LAT` decimal(9,7) DEFAULT NULL,
  `L_P_C_DTTM` int(11) DEFAULT NULL,
  `L_T_E_DTTM` int(11) DEFAULT NULL,
  `M_IND` varchar(20) DEFAULT NULL,
  `N_D_COUNTER` smallint(6) DEFAULT NULL,
  `O_ID` smallint(6) NOT NULL,
  `P_ID` varchar(50) DEFAULT NULL,
  `R_E_IND` smallint(6) DEFAULT NULL,
  `R_IND` smallint(6) DEFAULT NULL,
  `S_C_DTTM` varchar(20) DEFAULT NULL,
  `S_IND` smallint(6) DEFAULT NULL,
  `T_T_RED` varchar(20) DEFAULT NULL,
  `U_D` int(11) DEFAULT NULL,
  `V_D` int(11) DEFAULT NULL,
  `CRT_USR_NAM` varchar(45) DEFAULT NULL,
  `CRT_DTTM` varchar(45) DEFAULT NULL,
  `UPD_USR_NAM` varchar(45) DEFAULT NULL,
  `UPD_DTTM` varchar(45) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Мой запрос "где" будет в следующих столбцах для конкретного значения или комбинации значений 

C_ST_IND values range from (0,1,2,3,4,5,6,7,8,9,10,11,12)
E_IND values range from (0,1,2,3,4,5,6,7)
R_IND Values range from (0,1)
R_E_IND Values range from (0,1)
L_IND Values range from (0,1)
IS_D_IND Values range from (0,1)
I_S_IND Values range from (0,1)
I_P_IND Values range from (0,1)
I_IND Values range from (0,1)
S_IND Values range from (0,1,2,3)
H_B_IND Values range from (0,1)
O_ID Values range from (1,2,3,4,5,6)

Кроме того, мои столбцы даты в varchar с форматом - '2019-01-25 01:01:59' CRT_DTTM и UPD_DTTM

В среднем - дневная нагрузка составит 

CRT_DTTM    Count
2019-01-20  656601
2019-01-21  686018
2019-01-22  668486
2019-01-23  680922
2019-01-24  693700

Эта таблица содержит миллионы записей, которые в настоящее время и в настоящее время находятся в производстве, без каких-либо разделов и индексов.

На выполнение любого запроса уходит много времени.

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

Каковы наилучшие методы разбиения для перечисленных выше столбцов (часто используются в предложении where) и для столбцов даты (CRT_DTTM и UPD_DTTM) для Year, Month, Week и Day Partition , Также какие-либо индексы?

Эта таблица будет содержать данные за три года. Прямо сейчас у нас есть 3 месяца данных. Как переместить мою текущую таблицу в новую многораздельную таблицу. Я новичок в MySQL, любая информация поможет сократить время выполнения производственных запросов и генерацию отчетов.

1 Ответ

0 голосов
/ 26 января 2019

PARTITIONs по своей сути не обеспечивают какую-либо производительность.Давайте посмотрим на запросы, чтобы мы могли судить, есть ли у вас один из редких случаев, например, очистка «старых» данных.

Предлагаем сжать данные - SMALLINT занимает 2 байта;TINYINT UNSIGNED занимает 1 байт и может легко содержать все те небольшие значения, которые вы упомянули.7 знаков после запятой для широты / ширины дают точность менее 16 мм или менее одного дюйма.Вам нужна такая точность?Рассмотрим DECIMAL (8,6) для широты и (9,6) для долготы;это сэкономит 3 байта для каждой пары.(Хммм .. Почему две пары?)

"Долго ли можно было запускать" любой "запрос"?Давайте посмотрим на некоторые из них и поработаем над их оптимизацией.Обычная проблема заключается в том, что вам нужно коснуться множества строк.Сжатие строк (как упоминалось выше) поможет некоторым.Но большое улучшение заключается в том, что не затрагивается столько строк.

Это пахнет как приложение хранилища данных?Если это так, возможно, создание и ведение сводных таблиц - это путь.См. http://mysql.rjweb.org/doc.php/summarytables.Покажите мне больше информации, и я вам помогу.

Планируете ли вы очистить данные через 3 года?Если это так, я рекомендую разделять по месяцам и иметь 38 разделов.Подробности здесь: http://mysql.rjweb.org/doc.php/partitionmaint.При этом ночной ряд 680К DELETE становится на намного быстрее DROP PARTITION.(Между тем, вероятно, нет никакой пользы от выполнения запросов.)

My Index Cookbook: http://mysql.rjweb.org/doc.php/index_cookbook_mysql

...