Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Медленный запрос при наличии join'a таблицы  [new]
Supremumus
Member

Откуда:
Сообщений: 8
Добрый вечер.

Запрос с join'ом таблицы выполняется относительно долго, план запроса в аттаче
SELECT TOP (50)  * FROM Orchard_Framework_ContentItemVersionRecord cv 
inner join Orchard_Framework_ContentItemRecord ci on cv.ContentItemRecord_id=ci.Id 
inner join Cube_Orchard_Request_RentRequestRecord r on ci.Id=r.Id 
inner join Orchard_Framework_ContentTypeRecord ct on ci.ContentType_id=ct.Id 
WHERE r.Status in ('New') and r.OperatorId is null and cv.Published = 1


в то время как без join'a быстро и без лишних операций
SELECT TOP (50)  * FROM Orchard_Framework_ContentItemVersionRecord cv 
inner join Orchard_Framework_ContentItemRecord ci on cv.ContentItemRecord_id=ci.Id 
inner join Cube_Orchard_Request_RentRequestRecord r on ci.Id=r.Id 
--inner join Orchard_Framework_ContentTypeRecord ct on ci.ContentType_id=ct.Id 
WHERE r.Status in ('New') and r.OperatorId is null and cv.Published = 1


в чем может быть причина и как это исправить?

Индексы присутствуют на всех столбцах из запроса, в том числе и ci.ContentType_id

К сообщению приложен файл. Размер - 61Kb
27 мар 16, 20:39    [18984252]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
iljy
Member

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

причина тадиционно в том, что запросы разные. И информации предоставленной явно недостаточно, чтобы понять, где именно проблема. План запроса надо выкладывать в виде xml, а не картинки, причем планы обоих запросов, раз уж вы их сравниваете. Реальные планы, не ожидаемые. Дальше надо смотреть статистику io и процессора. Это так, беглый обзор с чего начать.
27 мар 16, 20:44    [18984270]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Supremumus
Member

Откуда:
Сообщений: 8
скрин плана второго запроса

К сообщению приложен файл. Размер - 58Kb
27 мар 16, 20:46    [18984277]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
iap
Member

Откуда: Москва
Сообщений: 47000
Supremumus,

как можно сравнивать разные запросы, которые возвращают разный результат?
JOIN, который вы закомментировали, приводит к тому, что записи с ci.ContentType_id,
для которых нет соответствующих записей в Orchard_Framework_ContentTypeRecord,
не попадут в результат. А второй запрос их вернёт не глядя.
Уж определитесь, что вам нужно.
27 мар 16, 20:47    [18984280]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Supremumus
Member

Откуда:
Сообщений: 8
iljy, планы в аттаче.

К сообщению приложен файл (plan.zip - 12Kb) cкачать
27 мар 16, 20:57    [18984300]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Supremumus
Member

Откуда:
Сообщений: 8
iap, не могу понять как запрос в котором все участвующие колонки с индексами, может содержать операцию с количеством чтений равным количеству строк в таблице.

Посоветуете книгу или статью, чтобы вникнуть в детали процесса?
27 мар 16, 21:06    [18984330]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Supremumus,

Дак у вас вложенные циклы. Количество чтений и будет соответствующее:
для каждой записи пробегается индекс+ еще раз пробегается кластерный (кей лукап) дабы достать нехватаюшие поля.
Каждый один такой "поиск по индексу" это несколько логических чтений;
1 На самом деле это не так уж и страшно, пока они логические. Все в оперативке
2 реально там всякие префетч и прочее

Вложенные циклы на больших соединениях весьма дорогое удовольствие. Напишите там hash join, чисто посмотреть
27 мар 16, 21:27    [18984394]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
iljy
Member

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

ну, и в этом плане видно, что предполагается выбирать из ContentItemRecord 1 строку, а реально выбирается 260т. Поэтому и долго. Сервер сгенерил неоптимальный план, бывает. Возможно, неактуальная статистика, возможно он просто некорректно оценивает селективность индекса. Как бороться - возможны варианты. Можно перестроить статистику, можно можно заменить * на список реально нужных полей, тогда уйдут Key Lookup. Если не поможет - можно попробовать использовать хинты в запросе (FORCE ORDER например).
27 мар 16, 21:29    [18984398]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
присоединяюсь к предыдущему оратору, если обновление статистики не поможет, то сдвинуть на первое место в плане выполнения таблицу Cube_Money_RentOrchard.. с помощью Force order
28 мар 16, 13:40    [18986135]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Akina
Member

Откуда: Зеленоград, Москва, Россия
Сообщений: 20585
Да и вообще запросы странненькие... "дай мне любые 50 записей из..."
28 мар 16, 13:53    [18986203]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Supremumus
Member

Откуда:
Сообщений: 8
iljy, обновление статистики решило проблему, спасибо.

Насчет * понимаю, я использую orm, поэтому запрос автогенеренный, хочу оттянуть момент необходимости изменения кода в C#.
30 мар 16, 13:38    [18995564]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Supremumus
Member

Откуда:
Сообщений: 8
Akina, почему странные? 50 элементов с определенным статусом.
30 мар 16, 13:39    [18995575]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
Supremumus
Akina, почему странные? 50 элементов с определенным статусом.

любые 50 элементов с определённым статусом
30 мар 16, 13:57    [18995687]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Akina
Member

Откуда: Зеленоград, Москва, Россия
Сообщений: 20585
Supremumus
почему странные? 50 элементов с определенным статусом

Какие-нибудь (всё равно, какие именно) 50 из всех с этим самым определённым статусом.
30 мар 16, 14:03    [18995734]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
iap
Member

Откуда: Москва
Сообщений: 47000
Supremumus
Akina, почему странные?
Потому что TOP() надо писать с ORDER BY
30 мар 16, 14:11    [18995792]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Supremumus
Member

Откуда:
Сообщений: 8
iap
Supremumus
Akina, почему странные?
Потому что TOP() надо писать с ORDER BY


Я думаю от этого запрос может, но не обязан стать быстрее? Упорядочится по одному из первичных ключей.
30 мар 16, 15:20    [18996267]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
_djХомяГ
Guest
Речь не про скорость, речь про саму логику запроса - как сказали выше беспорядочно (бессистемно) возвращаются записи
30 мар 16, 15:23    [18996273]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
iap
Member

Откуда: Москва
Сообщений: 47000
Supremumus
iap
пропущено...
Потому что TOP() надо писать с ORDER BY


Я думаю от этого запрос может, но не обязан стать быстрее? Упорядочится по одному из первичных ключей.
Что важнее: получить правильный результат или любой, но зато максимально быстро?
Ваш запрос возвращает случайный результат.
А с ORDER BY <НужныйВамПорядокПолейТочноЗадающийКакиеИменноПятьдесятЗаписейНужны> вернётся вполне определённый результат.
30 мар 16, 15:26    [18996288]     Ответить | Цитировать Сообщить модератору
 Re: Медленный запрос при наличии join'a таблицы  [new]
Supremumus
Member

Откуда:
Сообщений: 8
iap
Supremumus
пропущено...


Я думаю от этого запрос может, но не обязан стать быстрее? Упорядочится по одному из первичных ключей.
Что важнее: получить правильный результат или любой, но зато максимально быстро?
Ваш запрос возвращает случайный результат.
А с ORDER BY <НужныйВамПорядокПолейТочноЗадающийКакиеИменноПятьдесятЗаписейНужны> вернётся вполне определённый результат.


В моем случае, в приложении задается маппинг статусов на доступные способы сортировки, при наличии которых в запрос и добавляется нужная сортировка.
30 мар 16, 15:40    [18996332]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить