Штрафы за неиспользованные соединения - PullRequest
7 голосов
/ 02 мая 2011

Я пишу скрипт, который генерирует отчет на основе запроса, который использует несколько таблиц, объединенных вместе.Одним из входных данных для сценария будет список полей, обязательных для заполнения в отчете.В зависимости от запрошенных полей некоторые таблицы могут быть не нужны.Мой вопрос: есть ли [значительное] снижение производительности за включение объединения, если на него нет ссылки в предложении SELECT или WHERE?

Рассмотрим следующие таблицы:

mysql> SELECT * FROM `Books`;
+----------------------+----------+
| title                | authorId |
+----------------------+----------+
| Animal Farm          |        3 |
| Brave New World      |        2 |
| Fahrenheit 451       |        1 |
| Nineteen Eighty-Four |        3 |
+----------------------+----------+

mysql> SELECT * FROM `Authors`;
+----+----------+-----------+
| id | lastName | firstName |
+----+----------+-----------+
|  1 | Bradbury |       Ray |
|  2 |   Huxley |    Aldous |
|  3 |   Orwell |    George |
+----+----------+-----------+

SELECT
    `Authors`.`lastName`
FROM
    `Authors`
WHERE
    `Authors`.`id` = 1

Превышение:

SELECT
    `Authors`.`lastName`
FROM
    `Authors`
JOIN
    `Books`
    ON `Authors`.`id` = `Books`.`authorId`
WHERE
    `Authors`.`id` = 1

?

Мне кажется, что MySQL должен просто знать, что он полностью игнорирует JOIN, поскольку на таблицу не ссылаются вSELECT или WHERE предложение.Но почему-то я сомневаюсь, что это так.Конечно, это действительно простой пример.Фактические данные будут гораздо более сложными.

И на самом деле, это не очень большое дело ... Мне просто нужно знать, должен ли мой сценарий быть «умным» в отношении объединений, и включать их толькоесли запрашиваемые поля будут опираться на них.

Ответы [ 4 ]

3 голосов
/ 02 мая 2011

Это на самом деле не используется, поскольку это означает, что в набор результатов включаются только Авторы, которые существуют в Книгах.

JOIN
    `Books`
    ON `Authors`.`id` = `Books`.`authorId`

Однако, если бы вы «знали», что каждый Автор существует в Книге, чем былоНекоторый выигрыш в производительности при удалении объединения, но это будет в значительной степени зависеть от идексов и количества записей в таблице и логики в объединении (особенно при выполнении преобразований данных)

1 голос
/ 02 мая 2011

На этот вопрос невозможно ответить. Да, добавление объединения займет дополнительное время; невозможно сказать, сможешь ли ты измерить это время, ну ... ну ... не измерив время.

В общем, если - как в вашем примере - вы объединяете первичные ключи с уникальными индексами, это вряд ли измеримо изменится.

Если у вас есть более сложные объединения (на которые вы намекаете), или вы присоединяетесь к полям без индекса, или если ваше объединение включает функцию, снижение производительности может быть значительным.

Конечно, все еще может быть проще сделать так, чтобы написать несколько запросов, которые по сути одинаковы, кроме удаления ненужных объединений.

Последний совет - попробуйте абстрагировать запросы в представления. Таким образом, вы можете оптимизировать производительность один раз и, возможно, написать свои запросы к отчетам более простым способом ...

1 голос
/ 02 мая 2011

Присоединения всегда будут занимать время.

Побочные эффекты
Вдобавок к этому inner join (который является соединением по умолчанию) влияет на результат, ограничивая количество строк, которые вы получаете. Таким образом, в зависимости от того, находятся ли все authors в books, два запроса могут совпадать или не совпадать.

Также, если author записал более одного book, результирующий набор запроса 'join' покажет дублированные результаты.

Производительность
В предложении WHERE вы указали authors.id как константу =1, поэтому (при условии, что у вас есть индексы author.id и books.author_id) , это будет очень быстрый поиск для обоих столы. Время запроса между двумя таблицами будет очень близко.

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

0 голосов
/ 02 мая 2011

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

Похоже, что поскольку объединение действительно ограничивает возвращаемые результаты авторов, у которых есть книги в списке, то не может быть сделано столько оптимизации.

Также кажется, что для случая, когда вы описывали, где объединенная таблица действительно не оказывает ограничивающего влияния на возвращаемые результаты, запрос, в котором не было объединения таблиц, будет выполняться быстрее.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...