Запрос с тремя соединениями невероятно медленный

#mysql #sql #pdo #slim

#mysql #sql #pdo #тонкий

Вопрос:

Я пытаюсь вернуть все страны, в которых есть футбол, matches которые играют в определенном date . Данные определены в следующих таблицах:

соревнование

 id | country_id | name 
50       1         Premier League
  

соревнования_сезоны

 id | competition_id | name
 70       50          2019
  

competition_rounds

 id | season_id | name 
 58       70      Regular Season
  

совпадение

 id | round_id | home | away | result | datetime
 44      58       22     87     1 - 0  2019-03-16:00:00
  

В competition таблице хранятся разные соревнования, и тогда у каждого соревнования может быть несколько, season которые хранятся в competition_seasons . У season также могут быть разные конкуренты rounds , они хранятся в competition_rounds .

Все matches хранятся в match таблице и сгруппированы для round_id .

Я написал этот метод для API:

 $app->get('/country/get_countries/{date}', function (Request $request, Response $response, array $args)
{
  $start_date = $args["date"] . " 00:00";
  $end_date = $args["date"] . " 23:59";

  $sql = $this->db->query("SELECT n.* FROM country n
    LEFT JOIN competition c ON c.country_id = n.id
    LEFT JOIN competition_seasons s ON s.competition_id = c.id
    LEFT JOIN competition_rounds r ON r.season_id = s.id
    LEFT JOIN `match` m ON m.round_id = r.id
    WHERE m.datetime BETWEEN '" . $start_date . "' AND '" . $end_date . "'
    GROUP BY n.id");

  $sql->execute();
  $countries = $sql->fetchAll();
  return $response->withJson($countries);
});
  

существуют тысячи записей, организованных по идентификатору, но запросу потребовалось около 6-7 секунд, чтобы вернуть все countries , которые воспроизводятся в указанную дату.

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

Производительность

введите описание изображения здесь

Обновить

Я заметил интересную вещь, если я сделаю:

 SELECT round_id, DATE("2019-03-18") FROM `match`
  

запрос действительно быстрый, поэтому я предполагаю, что datetime поле замедляет часть соединения, есть идеи по этому поводу?

Структура таблицы

 CREATE TABLE IF NOT EXISTS `swp`.`competition` (
  `id` INT NOT NULL,
  `country_id` INT NULL,
  `name` VARCHAR(255) NULL,
  `category` INT NULL,
  PRIMARY KEY (`id`),
  INDEX `id_idx` (`country_id` ASC),
  INDEX `FK_competition_types_competition_type_id_idx` (`category` ASC),
  CONSTRAINT `FK_country_competition_country_id`
    FOREIGN KEY (`country_id`)
    REFERENCES `swp`.`country` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `FK_competition_categories_competition_category_id`
    FOREIGN KEY (`category`)
    REFERENCES `swp`.`competition_categories` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


CREATE TABLE IF NOT EXISTS `swp`.`competition_seasons` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `competition_id` INT NOT NULL,
  `season_id` INT NULL,
  `name` VARCHAR(45) NOT NULL,
  `update_at` DATETIME NULL,
  PRIMARY KEY (`id`),
  INDEX `FK_competition_competition_seasons_competition_id_idx` (`competition_id` ASC),
  CONSTRAINT `FK_competition_competition_seasons_competition_id`
    FOREIGN KEY (`competition_id`)
    REFERENCES `swp`.`competition` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `swp`.`competition_rounds` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `round_id` INT NULL,
  `season_id` INT NOT NULL,
  `name` VARCHAR(255) NULL,
  PRIMARY KEY (`id`),
  INDEX `FK_competition_seasons_competition_rounds_season_id_idx` (`season_id` ASC),
  CONSTRAINT `FK_competition_seasons_competition_rounds_season_id`
    FOREIGN KEY (`season_id`)
    REFERENCES `swp`.`competition_seasons` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `swp`.`match`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `swp`.`match` (
  `id` INT NOT NULL,
  `round_id` INT NOT NULL,
  `group_id` INT NULL,
  `datetime` DATETIME NULL,
  `status` INT NULL,
  `gameweek` INT NULL,
  `home_team_id` INT NULL,
  `home_team_half_time_score` INT NULL,
  `home_team_score` INT NULL,
  `home_extra_time` INT NULL,
  `home_penalties` INT NULL,
  `away_team_id` INT NULL,
  `away_team_half_time_score` INT NULL,
  `away_team_score` INT NULL,
  `away_extra_time` INT NULL,
  `away_penalties` INT NULL,
  `venue_id` INT NULL,
  `venue_attendance` INT NULL,
  `aggregate_match_id` INT NULL,
  PRIMARY KEY (`id`),
  INDEX `home_team_id_idx` (`home_team_id` ASC),
  INDEX `away_team_id_idx` (`away_team_id` ASC),
  INDEX `venue_id_idx` (`venue_id` ASC),
  INDEX `match_status_id_idx` (`status` ASC),
  INDEX `FK_competition_rounds_match_round_id_idx` (`round_id` ASC),
  INDEX `FK_match_match_aggregate_match_id_idx` (`aggregate_match_id` ASC),
  INDEX `FK_competition_groups_match_group_id_idx` (`group_id` ASC),
  CONSTRAINT `FK_team_match_home_team_id`
    FOREIGN KEY (`home_team_id`)
    REFERENCES `swp`.`team` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `FK_team_match_away_team_id`
    FOREIGN KEY (`away_team_id`)
    REFERENCES `swp`.`team` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `FK_venue_match_venue_id`
    FOREIGN KEY (`venue_id`)
    REFERENCES `swp`.`venue` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `FK_match_status_match_status_id`
    FOREIGN KEY (`status`)
    REFERENCES `swp`.`match_status` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `FK_competition_rounds_match_round_id`
    FOREIGN KEY (`round_id`)
    REFERENCES `swp`.`competition_rounds` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `FK_match_match_aggregate_match_id`
    FOREIGN KEY (`aggregate_match_id`)
    REFERENCES `swp`.`match` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `FK_competition_groups_match_group_id`
    FOREIGN KEY (`group_id`)
    REFERENCES `swp`.`competition_groups` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
  

Комментарии:

1. Почему левое соединение вместо внутреннего соединения? В конце концов, вам нужны записи, которые соответствуют всем критериям сразу

2. Используйте подготовленные инструкции. Не объединяйте строки.

3. @sfarzoso . . . Насколько велики таблицы (в строках)? Каков тип данных datetime ? Одинаковы ли типы данных ключей соединения? Вы можете добавить эту информацию в вопрос.

4. match таблица @GordonLinoff имеет размер 527,1 Мб, competition_seasons — 1,8 Мб, competition — 208 Кб и competition_rounds — 4 Мб

5. @sfarzoso . . . В плане объяснения, который вы опубликовали, первое сравнение должно быть >= , а не <= .

Ответ №1:

Сначала запишите запрос как:

 SELECT n.*
FROM country n JOIN
     competition c
     ON c.country_id = n.id JOIN
     competition_seasons s
     ON s.competition_id = c.id JOIN
     competition_rounds r
     ON r.season_id = s.id JOIN
     `match` m
     ON m.round_id = r.id
WHERE m.datetime >= ? AND
      m.datetime < ?
GROUP BY n.id;
  

Изменения здесь относительно незначительны и не повлияют на производительность. Но они важны:

  • JOIN вместо LEFT JOIN , потому что вы требуете, чтобы условия совпадали.
  • Параметры для даты вместо того, чтобы перегружать строку запроса, потому что это хорошая идея.
  • >= и < для сравнения, потому что это работает как с датами, так и со временем даты. Вам нужно будет добавить 1 день к конечной дате — но оставьте временную составляющую.

Затем, для повышения производительности, вам нужны индексы:

  • match(datetime, round_id)
  • competition_rounds(id, season_id)
  • competition_seasons(id, competition_id)
  • competition(id, country_id)
  • country(id)

На самом деле, первый — самый важный. Последние четыре не нужны, если соответствующие id столбцы объявлены как первичные ключи.

Комментарии:

1. Спасибо за подсказку, я действительно ценю это, в любом случае я не вижу никакой разницы в производительности, могу ли я что-нибудь сделать?

2. @sfarzoso . . . Предполагая, что вы добавили индексы, сколько времени занимает запрос без GROUP BY ? Я предполагаю, что есть всего несколько совпадений, которые удовлетворяют условию даты, поэтому GROUP BY должно быть дешево.

3. если я удалю GROUP BY , я получу дублированную страну и ту же проблему с производительностью

4. @sfarzoso . . . Сколько времени занимает этот простой запрос и сколько строк возвращается? select count(*) from match m where m.datetime >= ? and m.datetime < ?

5. @sfarzoso попробуйте выполнить приведенный выше SQL с ОБЪЯСНЕНИЕМ и опубликуйте результат здесь.

Ответ №2:

С LEFT JOIN запрос может выполняться только сверху вниз, что означает, что последняя таблица сканируется на предмет каждого произведения записей в предыдущих таблицах. Кроме того, использование LEFT JOIN и GROUP BY без какого-либо агрегата не имеет смысла, потому что он всегда будет возвращать все идентификаторы стран. Сказав это, я бы переписал его следующим образом:

 SELECT DISTINCT
    c.country_id
FROM 
    competition c,
WHERE 

    EXISTS (
        SELECT 
            *
        FROM
            competition_seasons s,
            competition_rounds r,
            `match` m
        WHERE
            s.competition_id = c.id
            AND r.season_id = s.id
            AND m.round_id = r.id 
            AND m.datetime BETWEEN ...
    )
  

Это будет правильно оптимизировано всеми известными мне RDB.
Обратите внимание, что индекс из 2 столбцов в (match.datetime, match.round_id) — в таком порядке окажет огромное влияние на производительность. Или скорость записи вызывает беспокойство, было бы рекомендовано, по крайней мере, индекс в одном столбце на (match.datetime) .

Важное замечание об индексах в строках: сравнение строк всегда сложно в RDBS. Убедитесь, что вы используете двоичную сортировку для столбца datetime или используете собственный формат DATETIME. Различные RDB могут не использовать индексы для столбцов без учета регистра.

Обратите внимание, что я удалил объединение в n — это просто добавить еще один поиск PK, чтобы проверить, что страна все еще существует в таблице countries. Вы можете добавить его обратно, если у вас нет КАСКАДА УДАЛЕНИЯ или другого ограничения, обеспечивающего согласованность данных, например:

 SELECT DISTINCT
    n.id
FROM 
    country n
WHERE 

    EXISTS (
        SELECT 
            *
        FROM
            competition c,
            competition_seasons s,
            competition_rounds r,
            `match` m
        WHERE
            c.country_id=n.id
            AND s.competition_id = c.id
            AND r.season_id = s.id
            AND m.round_id = r.id 
            AND m.datetime BETWEEN ...
    )
  

Комментарии:

1. Спасибо за ответ, к сожалению, ваш запрос действительно медленный в моей базе данных, занял около 24 секунд: imgur.com/a/1UHCdrT как вы можете видеть в моем вопросе, поле datetime имеет формат datetime

2. Можете ли вы опубликовать добавленный вами индекс? (SQL или изображение). Еще лучше, весь SQL таблицы (только структура). Используйте функцию экспорта в phpmyadmin.

3. Да, я обновил вопрос, если вы видите внизу, я добавил все таблицы, интересующие запрос

4. Итак … я не вижу никакого индекса в datetime.

5. Хорошо, но как я могу добавить индекс в datetime? Этот шаг мне непонятен