Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Агафоний
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] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47045 |
Агафоний, Вашу дату сервер хорошо понимает? А то ведь о чём-то более сложном даже говорить как-то неудобно... |
10 июн 13, 14:48 [14415325] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
Что значит "читаются"? В европейской цивилизации текст читается, традиционно, слева направо сверху вниз. :р Логическое выполнение селекта вот:
Вложенный подзапрос будет выпполнен для каждой строки "главного" запроса, на который он ссылается. Что именно вы хотите уточнить? |
||
10 июн 13, 14:53 [14415368] Ответить | Цитировать Сообщить модератору |
Агафоний
Guest |
Cammomile , Есть смысл выбирать между коррелированным и простым запросами? это влияет на производительность и скорость обработки запроса? |
10 июн 13, 14:57 [14415393] Ответить | Цитировать Сообщить модератору |
Cammomile Member Откуда: Сообщений: 1214 |
Запустите оба запроса, посмотрите планы ;-) |
10 июн 13, 15:20 [14415653] Ответить | Цитировать Сообщить модератору |
Crimean Member Откуда: Сообщений: 13148 |
Агафоний, а ничего, что ваши запросы совсем одинаковы? в первом пассаж "т1.код_пред = т2.код_пред" не имеет смысла же ибо тут же "[т1.]код_пред in (select [т2.]код_пред" алиасы пишем, не стесняемся - всем будет проще |
10 июн 13, 17:00 [14416532] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47045 |
Планы не одинаковы. |
||
10 июн 13, 17:32 [14416758] Ответить | Цитировать Сообщить модератору |
Crimean Member Откуда: Сообщений: 13148 |
iap, да ладно! повторил (только на своих данных) - одинаковые планы до тех пор пока условие по дате (применимо к начальному посту) не станет достаточно селективным. при этом сравнительные стоимости обоих вариантов условно равны и у меня, собственно, разница в планах (адаптируя к начальному посту) касалась выбираемого числа записей из таблица1 - когда их мало - оптимизатор уже не стесняется идти по некластерному в т1 и букмаркать. но пока их много - кластерный - наше все, как обычно |
10 июн 13, 18:44 [14417190] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
Вопрос интересней чем может показаться на первый взгляд, имхо. Во-первых, интересно что понимать под коррелированным запросом. Была тут где-то тема на форуме где много копий сломали и приводили разные определения. Не оспаривая терминологию, лично для себя, я считаю запрос коррелированным в том случае, когда оптимизатор не смог раскрыть подзапрос и выполняет подзапрос для каждой внешней по отношению к нему строки, т.к. в этом случае может страдать производительность. Если рассматривать ваш пример в таком контексте - то оптимизатор умеет раскрывать запросы такого типа, так что подзапрос не выполняется для каждой строки, однако, корреляция между таблицами разумеется остается. Во-вторых, оптимизатор умеет избавляться от противоречивых и избыточных условий. Но на это влияют множественные факторы. Например: - схема данных (nullable/not-nullable column, trusted foreign key, unique constraint и т.д.) - статистика и соответсвенно выбранный тип соединения - и даже...(вы не поверите, я и сам не поверил сперва =)) порядок указания таблиц в предикате where (дальше будет любопытный пример). Однако, в данном случае, оптимизатор, скорее плохо справляется со своей задачей исключения избыточности (хотя все выше перечисленные факторы не перестают работать). Кстати, интересно, что это можно использовать во благо, чтобы влиять на оценки и дальнейший план. Но можно и во вред, например, в случае доверенного FK - в одном случае внутренняя таблица будет исключена, в другом - нет. Резюме из вышесказанного: Ответ на ваш вопрос - как водится, it depends. В каждом конкретном случае, необходимо смотреть план, который будет зависеть от перечисленных выше условий. И, присоединяюсь к совету данному выше, посмотрите, что происходит в вашем случае. Да и просто замерьте время, чтения, процессор - посмотрите, что выгоднее. А теперь, как обещал, любопытный пример, который доказывает, что оптимизатор пишут люди, а не скайнет =) Для тестовой БД хватит даже БД opt, которую я обычно использую для экспериментов.
Теперь необходимо включить 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] Ответить | Цитировать Сообщить модератору |
Gios
Guest |
|
||
10 июн 13, 21:19 [14417601] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
На коленях умоляю. Хотя привычку писать условия в таком порядке я оставлю. |
||
10 июн 13, 21:20 [14417609] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
Да, согласен, имхо - баг. Декларативность как-то нарушается =) Если не лень, заводите айтем на коннект. Но, думаю, они забьют. Скажут бай дизайн и пользуйте exists. Там вроде все ок (специально на брутфорс не проверял и спец исследований не делал, но что видел - хоть in и exists часто (не путать с not in/not exist) приводят к одному плану - внутренне это разные ветки кода, разные деревья и разные функции). А вот что мне интересно. Анонсирован 2014. Главный козырь - Хекатон. Все кидаются на Хекатон (фас!). (Ну и плюс изменяемые и кластерные columnstore). Но! Есть сведения, что внесены изменения в Cardinality Estimation Framework. И в связи с этим вопрос - нам ждать новых планов? Или может они включили вот эти изменения в основной билд без всяких трейсфлагов? Кто знает... Интересно! |
||||
10 июн 13, 22:19 [14417780] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
Скорее всего, не всем понятно о чем я. Вот, интересная инфа о 2014. (Almost) Everything You Need to Know About SQL Server 2014 - Очень интересно! А вот что меня особенно беспокоит (может и напрасно): ![]() |
10 июн 13, 22:58 [14417942] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
SomewhereSomehow, И совсем не в тему. Но ощущения такие: Выучил Евгения Онегина наизусть. А Пушкин взял и еще пару томов написал, причем главного героя теперь зовут Геннадий =))) |
10 июн 13, 23:05 [14417973] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
SomewhereSomehow, А когда же мне багрепорт писать, кода стока инфы?!
А вот на счёт Генадия - если он оказался плохишом, то надо нашего маленького и мягкого :) котёночка носиком ткнуть в его ...нецо. А не откладывать багрепорты. ;) |
||
11 июн 13, 03:32 [14418337] Ответить | Цитировать Сообщить модератору |
Mnior Member Откуда: Кишинёв Сообщений: 6723 |
The Database Mirroring Endpoint:
По мне AlwaysOn AG это тот же мирроринг, только в профиль, и с питардой в жопе. Опять маркетинг? Это я к тому что одно дело "удивить" дибилея итак обделённого функционалом, а другое дело удивить программера, с его обширным знанием структур данных и теории вычислимости. Как бы не пошли статьи аля 100500 способ отстрелить себе ноги с SQL 2014.
Гуманитариев ублажают, а техников обижают. Путь идут в #опу. Скуль 2014 говно! Пусть доказывают обратное. ![]() |
||||||
11 июн 13, 04:39 [14418349] Ответить | Цитировать Сообщить модератору |
Guf Member Откуда: Новосибирск Сообщений: 658 |
Простите, а что там не так (картинку не видно)? У меня все 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] Ответить | Цитировать Сообщить модератору |
Ennor Tiegael Member Откуда: Сообщений: 3348 |
Guf, В первом запросе тип соединения - Right Semi Join, в остальных Inner Join. На самом деле я не думаю, что MSFT будет что-то фиксить. Больно уж извращенный случай, да и проще через exists написать, чем до такого додуматься. Покуда есть документированный workaround, они даже дергаться не будут. |
11 июн 13, 07:40 [14418422] Ответить | Цитировать Сообщить модератору |
Guf Member Откуда: Новосибирск Сообщений: 658 |
Ennor Tiegael, Черт! Провтыкал. Спасибо. |
11 июн 13, 07:43 [14418424] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
коррелированные запросы читаются сверху вниз, простые снизу вверх. Неверно. Оба можешь читать как тебе вздумается. коррелированный запрос — у тебя странный, его надо было вводить через exists : select код_пред, наименование, город from таблица1 т1 where exists (select код_пред from таблица2 т2 where т1.код_пред = т2.код_пред and дата = 18.05.2013) - В данном случае использовать лучше ПРОСТОЙ ЗАПРОС, т.к. сначала программа выберет из малой таблицы и после найдет это в большой. Неверно. Ты не можешь сказать, какой запрос будет выгоднее по производительности. Для этого надо смотреть планы физического выполнения запросов. Да и с точки зрения логики запросы эквивалентны и сервер имеет полное право один заменить другим или наоборот. Это SQL, декларативный язык запросов к данным, там нет никакой императивности, порядка вычисления частей и всего того, что ты выдумываешь. |
11 июн 13, 10:55 [14419092] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Нет, не влияет и смысла нет. Иметь смысл кричать запрос так, как этого требует его логика, чтобы сформулировать то, что он должен сделать наиболее естественным образом. |
||
11 июн 13, 10:58 [14419104] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Ребята, не надо грузить неофита планами, стоимостями, и прочими сложностями высшего порядка. |
11 июн 13, 11:03 [14419135] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Тем более что это не сложный запрос, это не вычитание, это простой join/distinct. |
11 июн 13, 11:05 [14419151] Ответить | Цитировать Сообщить модератору |
Агафоний
Guest |
руководствовался этим учебным пособием. задался вопросом, потому что не понял. |
||
11 июн 13, 13:48 [14420404] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47045 |
Используя корявый "русский" язык. Это ж надо, "снизу вверх"! А если я встану на голову, то будет "сверху вниз"? Сервер же строит общий план выполнения, не считаясь с порядком всяких там подзапросов. Какой план окажется эффективнее, такой и использует. |
||||
11 июн 13, 13:55 [14420461] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |