Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 простые и коррелированные  [new]
Агафоний
Guest
Поправьте пожалуйста, если я ошибаюсь!
коррелированные запросы читаются сверху вниз, простые снизу вверх.
-
просто примеры двух запросов
таблица1=100 тыс.строк. - таблица всех предприятий. код_пред, наименование, город
таблица2=10 тыс.строк. - таблица предприятий попавших в просрочку по отчетности код_пред, дата
надо сделать выборку по предприятиям попавшим в просрочку 18.05.2013
-
коррелированный запрос
select код_пред, наименование, город
from таблица1 т1
where код_пред in
(select код_пред
from таблица2 т2
where т1.код_пред = т2.код_пред and дата = 18.05.2013)

-
простой запрос
select код_пред, наименование, город
from таблица1 т1
where код_пред in
(select код_пред
from таблица2 т2
where дата = 18.05.2013)

В данном случае использовать лучше ПРОСТОЙ ЗАПРОС, т.к. сначала программа выберет из малой таблицы и после найдет это в большой. Для этого коррелированный и простой запрос? быстродействие? производительность?
Пытаюсь понять для чего все это.:(
Объясните простым языком. хелп
10 июн 13, 14:43    [14415283]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
iap
Member

Откуда: Москва
Сообщений: 47194
Агафоний,

Вашу дату сервер хорошо понимает?
А то ведь о чём-то более сложном даже говорить как-то неудобно...
10 июн 13, 14:48    [14415325]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Что значит "читаются"?
В европейской цивилизации текст читается, традиционно, слева направо сверху вниз. :р

Логическое выполнение селекта вот:

автор
FROM

ON

JOIN

WHERE

GROUP BY

WITH CUBE or WITH ROLLUP

HAVING

SELECT

DISTINCT

ORDER BY

TOP




Вложенный подзапрос будет выпполнен для каждой строки "главного" запроса, на который он ссылается.

Что именно вы хотите уточнить?
10 июн 13, 14:53    [14415368]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Агафоний
Guest
Cammomile ,
Есть смысл выбирать между коррелированным и простым запросами? это влияет на производительность и скорость обработки запроса?
10 июн 13, 14:57    [14415393]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Запустите оба запроса, посмотрите планы ;-)
10 июн 13, 15:20    [14415653]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Агафоний,

а ничего, что ваши запросы совсем одинаковы?
в первом пассаж "т1.код_пред = т2.код_пред" не имеет смысла же ибо тут же
"[т1.]код_пред in (select [т2.]код_пред"
алиасы пишем, не стесняемся - всем будет проще
10 июн 13, 17:00    [14416532]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
iap
Member

Откуда: Москва
Сообщений: 47194
Crimean
Агафоний,

а ничего, что ваши запросы совсем одинаковы?
в первом пассаж "т1.код_пред = т2.код_пред" не имеет смысла же ибо тут же
"[т1.]код_пред in (select [т2.]код_пред"
алиасы пишем, не стесняемся - всем будет проще
Совсем да не совсем.
Планы не одинаковы.
10 июн 13, 17:32    [14416758]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Crimean
Member

Откуда:
Сообщений: 13147
iap,

да ладно! повторил (только на своих данных) - одинаковые планы до тех пор пока условие по дате (применимо к начальному посту) не станет достаточно селективным. при этом сравнительные стоимости обоих вариантов условно равны
и у меня, собственно, разница в планах (адаптируя к начальному посту) касалась выбираемого числа записей из таблица1 - когда их мало - оптимизатор уже не стесняется идти по некластерному в т1 и букмаркать. но пока их много - кластерный - наше все, как обычно
10 июн 13, 18:44    [14417190]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Вопрос интересней чем может показаться на первый взгляд, имхо.

Во-первых, интересно что понимать под коррелированным запросом. Была тут где-то тема на форуме где много копий сломали и приводили разные определения. Не оспаривая терминологию, лично для себя, я считаю запрос коррелированным в том случае, когда оптимизатор не смог раскрыть подзапрос и выполняет подзапрос для каждой внешней по отношению к нему строки, т.к. в этом случае может страдать производительность. Если рассматривать ваш пример в таком контексте - то оптимизатор умеет раскрывать запросы такого типа, так что подзапрос не выполняется для каждой строки, однако, корреляция между таблицами разумеется остается.

Во-вторых, оптимизатор умеет избавляться от противоречивых и избыточных условий. Но на это влияют множественные факторы. Например:
- схема данных (nullable/not-nullable column, trusted foreign key, unique constraint и т.д.)
- статистика и соответсвенно выбранный тип соединения
- и даже...(вы не поверите, я и сам не поверил сперва =)) порядок указания таблиц в предикате where (дальше будет любопытный пример).
Однако, в данном случае, оптимизатор, скорее плохо справляется со своей задачей исключения избыточности (хотя все выше перечисленные факторы не перестают работать). Кстати, интересно, что это можно использовать во благо, чтобы влиять на оценки и дальнейший план. Но можно и во вред, например, в случае доверенного FK - в одном случае внутренняя таблица будет исключена, в другом - нет.

Резюме из вышесказанного:
Ответ на ваш вопрос - как водится, it depends. В каждом конкретном случае, необходимо смотреть план, который будет зависеть от перечисленных выше условий. И, присоединяюсь к совету данному выше, посмотрите, что происходит в вашем случае. Да и просто замерьте время, чтения, процессор - посмотрите, что выгоднее.

А теперь, как обещал, любопытный пример, который доказывает, что оптимизатор пишут люди, а не скайнет =)
Для тестовой БД хватит даже БД opt, которую я обычно использую для экспериментов.
+ opt
create database opt;
go
use opt;
go
create table t1(a int primary key, b int not null, c int check (c between 1 and 50));
create table t2(b int primary key, c int, d char(10));
create table t3(c int primary key);
go
insert into t1(a,b,c) select number, number%100+1, number%50+1 from master..spt_values where type = 'p' and number between 1 and 1000;
insert into t2(b,c) select number, number%100+1 from master..spt_values where type = 'p' and number between 1 and 1000;
insert into t3(c) select number from master..spt_values where type = 'p' and number between 1 and 1000;
go
alter table t1 add constraint fk_t2_b foreign key (b) references t2(b);


Теперь необходимо включить Actual Execution Plan и выполнить запросы:
use opt;
go
select * from t1 where t1.c in (select t2.b from t2 where t2.c = 10 and t2.b = t1.c);
select * from t1 where t1.c in (select t2.b from t2 where t2.c = 10);

select * from t1 where t1.c in (select t2.b from t2 where t2.c = 10 and t1.c = t2.b);

Картинка с другого сайта.
Проверялось на версиях:
Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) 
Microsoft SQL Server 2012 - 11.0.2100.60 (X64) 
Microsoft SQL Server 2008 R2 (SP2) - 10.50.4263.0 (X64) 
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 

Дело в том, что при оптимизации запроса есть такая стадия как Simplification (упрощение). Это еще не оптимизация, но некая пред-оптимизация. Входом является дерево логических операторов, выходом упрощенное дерево, которое затем отдается на оптимизацию. На этапе упрощения могут применяться различные правила упрощения. Правила применяются к определенным паттернам. Видимо, для данного случая, упустили из виду =)
10 июн 13, 19:26    [14417345]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Gios
Guest
Агафоний
where т1.код_пред = т2.код_пред and дата = 18.05.2013)

Выборка из 2-х таблиц, у которых совпадают поля. Никак иначе
10 июн 13, 21:19    [14417601]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6727
SomewhereSomehow
Видимо, для данного случая, упустили из виду
Гы, тёпленькое, срочно в баг репорт!!!
На коленях умоляю.

Хотя привычку писать условия в таком порядке я оставлю.
10 июн 13, 21:20    [14417609]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Mnior
SomewhereSomehow
Видимо, для данного случая, упустили из виду
Гы, тёпленькое, срочно в баг репорт!!!
На коленях умоляю.

Хотя привычку писать условия в таком порядке я оставлю.

Да, согласен, имхо - баг. Декларативность как-то нарушается =) Если не лень, заводите айтем на коннект.
Но, думаю, они забьют. Скажут бай дизайн и пользуйте exists. Там вроде все ок (специально на брутфорс не проверял и спец исследований не делал, но что видел - хоть in и exists часто (не путать с not in/not exist) приводят к одному плану - внутренне это разные ветки кода, разные деревья и разные функции).

А вот что мне интересно. Анонсирован 2014. Главный козырь - Хекатон. Все кидаются на Хекатон (фас!). (Ну и плюс изменяемые и кластерные columnstore). Но! Есть сведения, что внесены изменения в Cardinality Estimation Framework. И в связи с этим вопрос - нам ждать новых планов? Или может они включили вот эти изменения в основной билд без всяких трейсфлагов? Кто знает...

Интересно!
10 июн 13, 22:19    [14417780]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Скорее всего, не всем понятно о чем я.
Вот, интересная инфа о 2014.
(Almost) Everything You Need to Know About SQL Server 2014 - Очень интересно!

А вот что меня особенно беспокоит (может и напрасно):


Картинка с другого сайта.
10 июн 13, 22:58    [14417942]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
SomewhereSomehow,
И совсем не в тему. Но ощущения такие:
Выучил Евгения Онегина наизусть. А Пушкин взял и еще пару томов написал, причем главного героя теперь зовут Геннадий =)))
10 июн 13, 23:05    [14417973]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6727
SomewhereSomehow,
А когда же мне багрепорт писать, кода стока инфы?!

SomewhereSomehow
Выучил Евгения Онегина наизусть. А Пушкин взял и еще пару томов написал, причем главного героя теперь зовут Геннадий =)))
Нормально. Не надо прокасти откладывать чтение на потом. а обсуждать, обсуждать, обсуждать. И самому пописывать =)
А вот на счёт Генадия - если он оказался плохишом, то надо нашего маленького и мягкого :) котёночка носиком ткнуть в его ...нецо.
А не откладывать багрепорты. ;)
11 июн 13, 03:32    [14418337]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6727
SomewhereSomehow
(Almost) Everything You Need to Know About SQL Server 2014
Почти одна маркетинговая хрень. Многое для их же облака, и кое что экспериментального - жди засады. IMXO.

The Database Mirroring Endpoint:
BOL
The database mirroring feature will be removed in a future version of Microsoft SQL Server.
WTF?
По мне AlwaysOn AG это тот же мирроринг, только в профиль, и с питардой в жопе. Опять маркетинг?

Это я к тому что одно дело "удивить" дибилея итак обделённого функционалом, а другое дело удивить программера, с его обширным знанием структур данных и теории вычислимости.

Как бы не пошли статьи аля 100500 способ отстрелить себе ноги с SQL 2014.

внесены изменения в Cardinality Estimation Framework
Какие изменения конкретно. Как обычно не сказано ничего.
Гуманитариев ублажают, а техников обижают. Путь идут в #опу.
Скуль 2014 говно! Пусть доказывают обратное.
11 июн 13, 04:39    [14418349]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Guf
Member

Откуда: Новосибирск
Сообщений: 663
SomewhereSomehow
Теперь необходимо включить Actual Execution Plan и выполнить запросы:
use opt;
go
select * from t1 where t1.c in (select t2.b from t2 where t2.c = 10 and t2.b = t1.c);
select * from t1 where t1.c in (select t2.b from t2 where t2.c = 10);

select * from t1 where t1.c in (select t2.b from t2 where t2.c = 10 and t1.c = t2.b);

Простите, а что там не так (картинку не видно)? У меня все 3 плана одинаковые.
Microsoft SQL Server 2008 R2 (SP2) - 10.50.4263.0 (X64)
Aug 23 2012 15:56:56
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit)

К сообщению приложен файл. Размер - 74Kb
11 июн 13, 06:41    [14418392]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Ennor Tiegael
Member

Откуда:
Сообщений: 3448
Guf,

В первом запросе тип соединения - Right Semi Join, в остальных Inner Join.

На самом деле я не думаю, что MSFT будет что-то фиксить. Больно уж извращенный случай, да и проще через exists написать, чем до такого додуматься. Покуда есть документированный workaround, они даже дергаться не будут.
11 июн 13, 07:40    [14418422]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Guf
Member

Откуда: Новосибирск
Сообщений: 663
Ennor Tiegael,

Черт! Провтыкал. Спасибо.
11 июн 13, 07:43    [14418424]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
коррелированные запросы читаются сверху вниз, простые снизу вверх.

Неверно. Оба можешь читать как тебе вздумается.


коррелированный запрос — у тебя странный, его надо было вводить через exists :
select код_пред, наименование, город
from таблица1 т1
where exists
(select код_пред
from таблица2 т2
where т1.код_пред = т2.код_пред and дата = 18.05.2013)

-

В данном случае использовать лучше ПРОСТОЙ ЗАПРОС, т.к. сначала программа выберет из малой таблицы и после найдет это в большой.

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

Это SQL, декларативный язык запросов к данным, там нет никакой императивности, порядка вычисления частей и всего того, что ты выдумываешь.
11 июн 13, 10:55    [14419092]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Агафоний
Cammomile ,
Есть смысл выбирать между коррелированным и простым запросами? это влияет на производительность и скорость обработки запроса?



Нет, не влияет и смысла нет.
Иметь смысл кричать запрос так, как этого требует его логика, чтобы сформулировать то, что он должен сделать наиболее естественным образом.
11 июн 13, 10:58    [14419104]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Ребята, не надо грузить неофита планами, стоимостями, и прочими сложностями высшего порядка.
11 июн 13, 11:03    [14419135]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Тем более что это не сложный запрос, это не вычитание, это простой join/distinct.
11 июн 13, 11:05    [14419151]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
Агафоний
Guest
БАЗЫ ДАННЫХ ОСНОВЫ SQL РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
В зависимости от того, каким образом вложенный подзапрос взаимодействует с внешним подзапросом, их подразделяют на два вида: простые и коррелированные.
Простые вложенные подзапросы обрабатываются системой "снизу вверх". первым обрабатывается вложенный подзапрос самого нижнего уровня. Множество значений, полученное в результате его выполнения, используется при реализации подзапроса более высокого уровня и т.д.
Запросы с коррелированными вложенными подзапросами обрабатываются системой в обратном порядке. Сначала выбирается первая строка рабочей таблицы, сформированной основным запросом, и из нее выбираются значения тех столбцов, которые используются во вложенном подзапросе(вложенных подзапросах). Если эти значения удовлетворяют условиям вложенного подзапроса, то выбранная строка включается в результат. Затем выбирается вторая строка и т.д., пока в результат не будут включены все строки, удовлетворяющие вложенному подзапросу (последовательности вложенных подзапросов).
-
Учебное пособие.
Санкт-Петербург 2005
М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова

руководствовался этим учебным пособием.
задался вопросом, потому что не понял.
11 июн 13, 13:48    [14420404]     Ответить | Цитировать Сообщить модератору
 Re: простые и коррелированные  [new]
iap
Member

Откуда: Москва
Сообщений: 47194
Агафоний
БАЗЫ ДАННЫХ ОСНОВЫ SQL РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
В зависимости от того, каким образом вложенный подзапрос взаимодействует с внешним подзапросом, их подразделяют на два вида: простые и коррелированные.
Простые вложенные подзапросы обрабатываются системой "снизу вверх". первым обрабатывается вложенный подзапрос самого нижнего уровня. Множество значений, полученное в результате его выполнения, используется при реализации подзапроса более высокого уровня и т.д.
Запросы с коррелированными вложенными подзапросами обрабатываются системой в обратном порядке. Сначала выбирается первая строка рабочей таблицы, сформированной основным запросом, и из нее выбираются значения тех столбцов, которые используются во вложенном подзапросе(вложенных подзапросах). Если эти значения удовлетворяют условиям вложенного подзапроса, то выбранная строка включается в результат. Затем выбирается вторая строка и т.д., пока в результат не будут включены все строки, удовлетворяющие вложенному подзапросу (последовательности вложенных подзапросов).
-
Учебное пособие.
Санкт-Петербург 2005
М.В. Копейкин, В.В. Спиридонов, Е.О. Шумова

руководствовался этим учебным пособием.
задался вопросом, потому что не понял.
Авторы пытаются объяснить логический порядок выполнения запроса с подзапросами.
Используя корявый "русский" язык.
Это ж надо, "снизу вверх"! А если я встану на голову, то будет "сверху вниз"?

Сервер же строит общий план выполнения, не считаясь с порядком всяких там подзапросов.
Какой план окажется эффективнее, такой и использует.
11 июн 13, 13:55    [14420461]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить