подвыберите по сравнению с внешним объединением
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
8 ответов
RDBMSs "переписывают" запросы для оптимизации их, таким образом, это зависит от системы, Вы используете, и я предположил бы, что они заканчивают тем, что дали ту же производительность на самых "хороших" базах данных.
Я предлагаю выбрать тот, который более ясен и легче поддержать за мои деньги, это - первое. Намного легче отладить подзапрос, поскольку это может быть выполнено независимо для проверки на исправность.
несвязанные подзапросы прекрасны. необходимо пойти с тем, что описывает данные, которые Вы желаете. как был отмечен, это, вероятно, переписывается в тот же план, но не гарантируется! кроме того, если таблица A и B не будут 1:1, то Вы получите дублирующиеся кортежи от запроса соединения (поскольку В пункте выполняет неявный ОТЛИЧНЫЙ вид), таким образом, всегда лучше кодировать то, что Вы хотите и на самом деле думаете о результате.
Ну, это зависит от наборов данных. На основе моего опыта, если у Вас есть небольшой набор данных затем, идут для НЕ В ТОМ, если это - большое движение для ЛЕВОГО СОЕДИНЕНИЯ. НЕ В Пункте, кажется, является очень медленным на больших наборах данных.
Еще одна вещь, которую я мог бы добавить, состоит в том, что объяснить планы могли бы вводить в заблуждение. Я видел несколько запросов, где объясняют, было небо высоко и запрос, выполненный под 1 с. С другой стороны, я видел, что запросы с превосходным объясняют план, и они могли работать в течение многих часов.
Так, в целом, протестируйте на своих данных и лично убедитесь.
Я ответ второго Tom, что необходимо выбрать тот, который легче понять и поддержать.
План запросов любого запроса в любой базе данных не может быть предсказан, потому что Вы не дали нам дистрибутивы данных или индексы. Единственный способ предсказать, который быстрее, состоит в том, чтобы выполнить их против Вашей базы данных.
Как показывает опыт, я склонен использовать, подвыбирает, когда я не должен включать столбцы от tblB в моем избранном пункте. Я определенно пошел бы для подвыбора, когда я хочу использовать 'в' предикате (и обычно для 'не в', который Вы включали в вопрос), по простой причине, что они легче понять, когда Вы или кто-то еще возвратились и изменяете их.
Первый запрос будет быстрее в SQL Server, который я думаю, интуитивный счетчик slighty - запросы Sub кажутся, что должны быть медленнее. В некоторых случаях (поскольку объемы данных увеличиваются), exists может быть быстрее, чем in.
От моих наблюдений сервер MSSQL производит тот же план запросов для этих запросов.
Я создал простой запрос, подобный тем в вопросе на MSSQL2005, и объяснить планы отличались. Первый запрос, кажется, быстрее. Я не эксперт SQL, но предполагаемые объясняют, что план имел 37% для запроса 1 и 63% для запроса 2. Кажется, что самая большая стоимость для запроса 2 является соединением. Оба запроса имели два сканирования таблицы.
Нужно отметить, что эти запросы приведут к различным результатам, если TblB.a не будет уникален.