Коррелированный подзапрос может стать проблемой производительности, когда внешний запрос обрабатывает большое количество строк;потому что подзапрос выполняется для каждой строки.
Похоже, что этот запрос возвращает не более одной строки, потому что похоже, что user_id
является уникальным ключом.Поскольку внешний запрос возвращает (самое большее) одну строку, подзапрос будет выполнен только один раз.
Также похоже, что user_group_id
- это уникальный ключ в таблице user_group
, так что подзапрос будетверните не более одного ряда.(В более общем случае, если подзапрос возвращает более одной строки, мы получили бы ошибку. С помощью LEFT JOIN мы получили бы несколько строк.)
Q: Есть ли какое-либо улучшение производительности при использовании подзапроса в столбце «Выбор»?
A: С какой-либо формой снижение производительности не будет.Форма с коррелированным подзапросом может быть быстрее, но разница не значительна.
В: Если да, то как?Если нет, то почему это основное сообщество использует этот способ?
A: Это допустимый SQL, он работает, и нет никаких стимулов для внесения изменений.
Q:Кроме того, я обнаружил, что они не используют внешние ключи, есть идеи почему?
A: Нет необходимости в том, чтобы СУБД обеспечивала ссылочную целостность;если приложение обрабатывает его, то мы можем избежать накладных расходов в базе данных.
Некоторые механизмы хранения (например, MyISAM) не применяют ограничения внешнего ключа.
И внешние ключи могут иногда мешатьадминистративные операции, такие как очистка и перезагрузка таблицы.
Это все проектные решения;Есть несколько способов снять кожу с кошки.(Мы просто просматриваем поверхность; погружение глубже будет основано на мнении, чтобы аргументировать, какой способ лучше обшарить кошку.)