Влияние разделения Mysql на DDL и DML

Я использую Mysql 5.6 с ~ 150 миллионами записей в таблице транзакций (InnodB). По мере увеличения размера эта таблица становится неуправляемой (добавление столбца или индекса) и замедляется даже при обязательном индексировании. После поиска в Интернете я обнаружил, что пришло время разбить таблицу. Я уверен, что разделение решит следующую задачу для меня

  1. Улучшить время отклика операторов DML (используя отсечение секционирования)
  2. Улучшить архивный процесс

Но я не уверен, улучшит ли это (и как) производительность DDL для этой таблицы или нет. В частности, после производительности DDL.

  1. ИЗМЕНИТЬ ТАБЛИЦУ ДОБАВИТЬ/УДАЛИТЬ СТОЛБЦ
  2. ИЗМЕНИТЬ ТАБЛИЦУ ДОБАВИТЬ/УДАЛИТЬ ИНДЕКС

Я просмотрел документацию Mysql и Интернет, но не смог найти ответ. Может ли кто-нибудь помочь мне в этом или предоставить любую соответствующую документацию для этого.

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

CREATE TABLE `TRANSACTION` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `parent_id` int(11) DEFAULT NULL,
  `parent_uuid` char(36) DEFAULT NULL,
  `order_number` varchar(64) DEFAULT NULL,
  `order_id` int(11) DEFAULT NULL,
  `order_uuid` char(36) DEFAULT NULL,
  `order_type` char(1) DEFAULT NULL,
  `business_id` int(11) DEFAULT NULL,
  `store_id` int(11) DEFAULT NULL,
  `store_device_id` int(11) DEFAULT NULL,
  `source` char(1) DEFAULT NULL COMMENT 'instore, online, order_ahead, etc',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  `flags` int(11) DEFAULT NULL,
  `customer_lang` char(2) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `parent_id` (`parent_id`),
  KEY `business_id` (`business_id`,`store_id`,`store_device_id`),
  KEY `parent_uuid` (`parent_uuid`),
  KEY `order_uuid` (`order_uuid`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

И я разделяю, используя следующий оператор.

ALTER TABLE TRANSACTION PARTITION BY RANGE (id)
(PARTITION p0 VALUES LESS THAN (5000000) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (10000000) ENGINE = InnoDB,
 PARTITION p2 VALUES LESS THAN MAXVALUE ENGINE = InnoDB)

Спасибо!


person r.bhardwaj    schedule 04.12.2018    source источник
comment
Какой табличный движок, потому что InnoDB поддерживает онлайн-DLL... Кроме того, разбиение на разделы не является серебряной пулей, чтобы всегда решать проблемы с производительностью. И некоторые типы разбиения лучше подходят, чем другие, поэтому это зависит от того, какой тип вам нужен. Вы должны поделиться SHOW CREATE TABLE table утверждение и пример того, как или в каком столбце вы хотите использовать разбиение, прежде чем мы сможем что-то предложить или дать совет.   -  person Raymond Nijland    schedule 04.12.2018
comment
@RaymondNijland Спасибо за ответ, я обновил схему таблицы и операторы разделения в вопросе.   -  person r.bhardwaj    schedule 04.12.2018


Ответы (1)


Разделение не является панацеей производительности. Даже упомянутые вами предметы не будут ускоряться; они могут даже замедлиться.

Вместо этого я буду критиковать таблицу, чтобы найти способы ускорить некоторые вещи.

  • UUID ужасны для производительности, когда индекс становится слишком большим для кэширования. Это связано с его случайностью. Возможные решения: сжать его в BINARY(16); уменьшать таблицу другими способами; избегайте UUID.
  • Почему есть и parent_id, и parent_uuid??
  • Сократите 4-байтовый INTs до меньших типов данных там, где это целесообразно.
  • Обычно CHAR должно быть CHARACTER SET ascii (1 байт/символ), а не utf8mb4 (4 байта/символ).
  • Осторожно: 150 М приближается к пределу в 2 миллиарда — INT SIGNED. Рассмотрим предел 4B INT UNSIGNED. (Каждый 4 байта.)
  • Вы когда-нибудь использовали created_at или updated_at?
  • MySQL 8.0.13 имеет очень быстрые ADD COLUMN и DROP COLUMN (для ограниченных ситуаций).
  • 5.7.?? имеет менее инвазивный ADD INDEX, чем в предыдущих версиях, но я не уверен, что он применим к секционированным таблицам.
  • 5.7.4: Онлайн-поддержка DDL сокращает время перестроения таблиц и позволяет использовать параллельный DML, что помогает сократить время простоя пользовательских приложений. Для получения дополнительной информации см. Обзор онлайн-DDL.

Что еще более важно, давайте посмотрим на основные запросы, которые «слишком медленные». Могут быть составные индексы и/или переформулировки запросов, которые ускорят их.

Есть даже небольшой шанс, что разбиение на разделы поможет, но не на PRIMARY KEY.

Я думаю, что есть только 4 варианта использования, где разделение помогает спектакль.

person Rick James    schedule 05.12.2018
comment
Спасибо за информацию, производительность - не единственная причина, по которой мы хотим разделить ее в основном на обслуживание большой таблицы. Итак, даже после рассмотрения вышеизложенных пунктов, если мы хотим разделить, может ли это улучшить производительность DDL? - person r.bhardwaj; 05.12.2018
comment
@ r.bhardwaj - я почти уверен, что ответ бесполезен для обслуживания. Подумайте об этом так: если в одном разделе есть новые индексы, а в других нет, как, черт возьми, должен работать запрос? - person Rick James; 05.12.2018