Реальный вопрос: есть ли у этих записей отношение один к одному или отношение один ко многим ?
Ответ TLDR:
Если один на один, используйте JOIN
утверждение.
Если один ко многим, используйте один (или много) SELECT
операторов с оптимизацией кода на стороне сервера.
Почему и как использовать SELECT для оптимизации
SELECT
Использование (с несколькими запросами вместо объединений) для большой группы записей на основе отношения «один ко многим» обеспечивает оптимальную эффективность, поскольку в случае с JOIN
проблемой экспоненциальной утечки памяти. Соберите все данные, а затем используйте язык сценариев на стороне сервера, чтобы разобраться в них:
SELECT * FROM Address WHERE Personid IN(1,2,3);
Полученные результаты:
Address.id : 1 // First person and their address
Address.Personid : 1
Address.City : "Boston"
Address.id : 2 // First person's second address
Address.Personid : 1
Address.City : "New York"
Address.id : 3 // Second person's address
Address.Personid : 2
Address.City : "Barcelona"
Здесь я получаю все записи в одном операторе выбора. Это лучше, чем JOIN
, что бы получить небольшую группу этих записей, по одной, как подкомпонент другого запроса. Затем я анализирую его с помощью серверного кода, который выглядит примерно так ...
<?php
foreach($addresses as $address) {
$persons[$address['Personid']]->Address[] = $address;
}
?>
Когда не использовать JOIN для оптимизации
JOIN
большая группа записей, основанная на взаимно-однозначных отношениях с одной записью, обеспечивает оптимальную эффективность по сравнению с множеством SELECT
операторов один за другим, которые просто получают следующий тип записи.
Но JOIN
неэффективно при получении записей с отношением один ко многим.
Пример: Блоги базы данных имеют 3 таблицы интереса: Blogpost, Tag и Comment.
SELECT * from BlogPost
LEFT JOIN Tag ON Tag.BlogPostid = BlogPost.id
LEFT JOIN Comment ON Comment.BlogPostid = BlogPost.id;
Если есть 1 запись блога, 2 тега и 2 комментария, вы получите следующие результаты:
Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag2, comment1,
Row4: tag2, comment2,
Обратите внимание, как дублируется каждая запись. Итак, 2 комментария и 2 тега - это 4 строки. Что если у нас есть 4 комментария и 4 тега? Вы не получаете 8 строк - вы получаете 16 строк:
Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag1, comment3,
Row4: tag1, comment4,
Row5: tag2, comment1,
Row6: tag2, comment2,
Row7: tag2, comment3,
Row8: tag2, comment4,
Row9: tag3, comment1,
Row10: tag3, comment2,
Row11: tag3, comment3,
Row12: tag3, comment4,
Row13: tag4, comment1,
Row14: tag4, comment2,
Row15: tag4, comment3,
Row16: tag4, comment4,
Добавьте больше таблиц, больше записей и т. Д., И проблема быстро раздуется до сотен строк, которые заполнены в основном избыточными данными.
Сколько стоят эти дубликаты? Память (в SQL-сервере и коде, который пытается удалить дубликаты) и сетевые ресурсы (между SQL-сервером и вашим сервером кода).
Источник: https://dev.mysql.com/doc/refman/8.0/en/nested-join-optimization.html ; https://dev.mysql.com/doc/workbench/en/wb-relationship-tools.html