Плохой запрос при сканировании таблицы иногда занимает часы на MariaDB

Question

Мое приложение использует базу данных MariaDB, которую я пытаюсь сохранить изолированной, но один конкретный пользователь сразу же отправил жалобу в базу данных и через 6 недель начал жаловаться на то, что один из их запросов замедлился с 5 минут (что я считаю плохим)достаточно) до более чем 120 минут.

С тех пор сегодня это иногда было так же быстро, как обычно, иногда снова замедлялось.

Это их запрос:

SELECT MAX(last_updated) FROM data_points;

Это таблица:

CREATE TABLE data_points (
  seriesId INT UNSIGNED NOT NULL,
  modifiedDate DATE NOT NULL,
  valueDate DATE NOT NULL,
  value DOUBLE NOT NULL,
  created DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  last_updated DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP()
    ON UPDATE CURRENT_TIMESTAMP,
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  CONSTRAINT pk_data PRIMARY KEY (seriesId, modifiedDate, valueDate),
  KEY ix_data_modifieddate (modifiedDate),
  KEY ix_data_id (id),
  CONSTRAINT fk_data_seriesid FOREIGN KEY (seriesId)
  REFERENCES series(id)
) ENGINE=InnoDB
  DEFAULT CHARSET=utf8mb4
  COLLATE=utf8mb4_unicode_ci
  MAX_ROWS=222111000;

и это ОБЪЯСНЕНИЕ:

id      select_type     table       type    possible_keys   key     key_len ref     rows    Extra
1       SIMPLE          data_points ALL     NULL            NULL    NULL            NULL    224166191

Таблица содержит около 250 миллионов строк и растет относительно быстро.

Я могу заставить пользователя сделать что-то более разумное, но в краткосрочной перспективе я хочу понять, почему длительность запроса сходит с ума сегодня после 6 недельспокойный.Я приму первый ответ, который может это объяснить.

Answer 1

SELECT MAX(last_updated) FROM data_points; легко оптимизируется:

INDEX(last_updated)

Этот индекс сделает MAX практически мгновенным.И это позволит избежать стука по диску и кешу (см. Ниже).

Две вещи управляют неиндексированной скоростью:

• Размер таблицы, которая «растет относительноfast ", и
• [Это, вероятно, то, что вы ищете.] Какая часть таблицы кэшируется при выполнении запроса.Это может увеличить скорость в 10 раз.Вы можете частично проверить это утверждение следующим образом:

Перезапустите mysqld;время запроса;время сноваПервый запуск должен был сильно ударить по диску (из-за свежего перезапуска);второй может найти все в ОЗУ.

Еще одна вещь, которая может испортить время: если выполняется какой-то другой «большой» запрос, и он удаляет блоки этой таблицы из кэша, тогда запрос снова будетмедленно.

Уместно: размер таблицы, значение innodb_buffer_pool_size и объем оперативной памяти.

По не связанной теме ... Это PRIMARY KEY (seriesId, modifiedDate, valueDate) кажется странным.ПК должен быть уникальным.Даты (дата и т. Д.) Могут содержать несколько записей для одного дня / секунды;так что вы можете быть уверены в уникальности?Особенно с 2 датами?

(Подробнее)

Пожалуйста, объясните значение каждой из 4 дат.И спросите себя, все ли они нужны.(Около половины основной части таблицы составляют эти даты!)

Таблица имеет AUTO_INCREMENT;это нужно какой-то другой таблице?Если нет, то или можно удалить, или , чтобы убедиться, что PK уникален.

Чтобы лучше помочь вам, нам нужно увидеть большезапросов.