Эффект разделения MySQL на DDL и DML

Question

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

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

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

1. ALTER TABLE ADD / DROP COLUMN
2. ALTER TABLE ADD / DROP INDEX

Я просмотрел документацию по 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)

Спасибо!

Answer 1

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

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

• UUID ужасно влияют на производительность, когда индекс для него становится слишком большимбольшой для кэширования.Это из-за его случайности.Возможные решения: сжать в BINARY(16);сжать стол другими способами;избегайте UUID.
• Почему и parent_id, и parent_uuid ??
• Сократите 4-байтовый INTs до меньших типов данных , где это возможно .
• Обычно CHAR должно быть CHARACTER SET ascii (1 байт / символ), а не utf8mb4 (4 байта / символ).
• Внимание: 150M приближается к пределу в 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 случаях использования , где разбиение помогает повысить производительность.