Запрашивать запись в одном разделе очень медленно - PullRequest
Новая
       13

Запрашивать запись в одном разделе очень медленно

0 голосов
/ 12 февраля 2019

У меня есть большая таблица (более 2 миллиардов записей), которая разбита на разделы.Каждый раздел содержит около 500 миллионов записей.Недавно я перешел с физического оборудования на AWS, я использовал mysqldump для резервного копирования и восстановления данных MySQL.Я также недавно создал новый раздел (p108).Запросы данных из старых разделов (созданных на старом сервере) выполняются как обычно, очень быстро, возвращая данные в считанные секунды.Однако запрос записей во вновь созданном разделе (p108) очень медленный - минуты.

show create table результаты 

CREATE TABLE `termusage` 
  ( 
     `id`            BIGINT(20) NOT NULL auto_increment, 
     `terminal`      BIGINT(20) DEFAULT NULL, 
     `date`          DATETIME DEFAULT NULL, 
     `dest`          VARCHAR(255) DEFAULT NULL, 
     `feattrans`     BIGINT(20) DEFAULT NULL, 
     `cost_type`     TINYINT(4) DEFAULT NULL, 
     `cost`          DECIMAL(16, 6) DEFAULT NULL, 
     `gprsup`        BIGINT(20) DEFAULT NULL, 
     `gprsdown`      BIGINT(20) DEFAULT NULL, 
     `duration`      TIME DEFAULT NULL, 
     `file`          BIGINT(20) DEFAULT NULL, 
     `custcost`      DECIMAL(16, 6) DEFAULT '0.000000', 
     `invoice`       BIGINT(20) NOT NULL DEFAULT '99999999', 
     `carriertrans`  BIGINT(20) DEFAULT NULL, 
     `session_start` DATETIME DEFAULT NULL, 
     `session_end`   DATETIME DEFAULT NULL, 
     `mt_mo`         VARCHAR(4) DEFAULT NULL, 
     `grps_rounded`  BIGINT(20) DEFAULT NULL, 
     `gprs_rounded`  BIGINT(20) DEFAULT NULL, 
     `country`       VARCHAR(25) DEFAULT NULL, 
     `network`       VARCHAR(25) DEFAULT NULL, 
     `ctn`           VARCHAR(20) DEFAULT NULL, 
     `pricetrans`    BIGINT(20) DEFAULT NULL, 
     PRIMARY KEY (`id`, `invoice`), 
     KEY `idx_terminal` (`invoice`, `terminal`), 
     KEY `idx_feattrans` (`invoice`, `feattrans`), 
     KEY `idx_file` (`invoice`, `file`), 
     KEY `termusage_carriertrans_idx` (`carriertrans`), 
     KEY `idx_ctn` (`invoice`, `ctn`), 
     KEY `idx_pricetrans` (`invoice`, `pricetrans`) 
  ) 
engine=innodb 
auto_increment=17449438880 
DEFAULT charset=latin1 
/*!50500 PARTITION BY RANGE  COLUMNS(invoice) 
(PARTITION p103 VALUES LESS THAN (621574) ENGINE = InnoDB, 
 PARTITION p104 VALUES LESS THAN (628214) ENGINE = InnoDB, 
 PARTITION p106 VALUES LESS THAN (634897) ENGINE = InnoDB, 
 PARTITION p107 VALUES LESS THAN (649249) ENGINE = InnoDB, 
 PARTITION p108 VALUES LESS THAN (662763) ENGINE = InnoDB, 
 PARTITION plast VALUES LESS THAN (MAXVALUE) ENGINE = InnoDB) */

Я создал раздел p108, используя следующий запрос 

ALTER TABLE termusage reorganize partition plast 
INTO        ( partition p108 VALUES less than (662763), 
              partition plast VALUES less than maxvalue )

Я могу видеть файл termusage#p#p108.ibd и выглядит как "нормальный", и данные есть, так как я могу получить результаты запроса.

information_schema.PARTITIONS показывает следующее длятаблица - которая указывает на наличие какой-либо проблемы 

Name    Pos Rows        Avg Data Length Method
p103    1   412249206   124 51124371456 RANGE COLUMNS
p104    2   453164890   133 60594061312 RANGE COLUMNS
p106    3   542767414   135 73562849280 RANGE COLUMNS
p107    4   587042147   129 76288098304 RANGE COLUMNS
p108    5   0           0   16384       RANGE COLUMNS
plast   6   0           0   16384       RANGE COLUMNS

Как я могу исправить раздел?

Обновлено

Объяснить для хорошего запроса 

# id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, Extra
1, SIMPLE, t, p107, ref, idx_terminal,idx_feattrans,idx_file,idx_ctn,idx_pricetrans, idx_terminal, 17, const,const, 603, 100.00, Using index condition; Using temporary; Using filesort

Объясните для плохого запроса 

# id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, Extra
1, SIMPLE, t, p108, ALL, idx_terminal,idx_feattrans,idx_file,idx_ctn,idx_pricetrans, , , , 1, 100.00, Using where; Using temporary; Using filesort

1 Ответ

0 голосов
/ 12 февраля 2019

Для будущих читателей проблема была решена путем запуска ALTER TABLE ... ANALYZE PARTITION p108.

Статистика таблиц и индексов, которая помогает оптимизатору выбрать лучший способ чтения таблицы, устарела.Обычно используется ANALYZE, чтобы убедиться, что эти статистические данные обновляются после значительной загрузки или удаления данных.

...