SQL - низкая производительность запросов при объединении двух представлений с помощью предложения Where
Я выполняю следующий запрос в SQL Server, который дает мне результат всего за 5 секунд с более чем 80000 строками и 75+ столбцами:
SELECT * FROM VIEW_ITEM_STOCK_LEDGER AS ItemLedger
LEFT JOIN VIEW_PRODUCT_WITH_CHARACTERISTIC_COLUMN_DATA AS Characteristics
ON Characteristics.Code = ItemLedger.ItemCode
Но когда я добавляю в запрос предложение WHERE, выполнение запроса занимает слишком много времени. Для 13450 записей требуется более 5 минут.
SELECT * FROM VIEW_ITEM_STOCK_LEDGER AS ItemLedger
LEFT JOIN VIEW_PRODUCT_WITH_CHARACTERISTIC_COLUMN_DATA AS Characteristics
ON Characteristics.Code = ItemLedger.ItemCode
WHERE (ItemLedger.VoucherTypeCode=204 OR ItemLedger.VoucherTypeCode=205)
Что может быть причиной? Как мне решить эту проблему?
@ Ajay2707: почему ты думаешь, что это будет иметь значение?
@MitchWheat: подумайте, пока фильтруйте данные через сервер соединения, а затем, где условие сначала фильтрует данные на основе условия соединения, а затем на втором шаге, где условие применяется к фильтру. Я знаю, что представления замедляют запрос, если в представлениях несколько таблиц. Таким образом, при условии, что условие перехода в соединение даст некоторое ускорение.
@MitchWheat Нет Оба представления взяты из других таблиц
@ Ajay2707 Я попытался сократить это условие и поставить непосредственно на представление VIEW_ITEM_STOCK_LEDGER, но производительность все равно низкая. Как sql выполняет запросы?
показать определения расширенного вида
почему ты присоединяешься? поправьте меня, если я ошибаюсь. В своем заявлении select * from VIEW_ITEM_STOCK_LEDGER вы просто вызываете все данные и столбец из этого представления, и вы делаете Left Join для другого представления и ничего не делаете, кроме того, что связано с вашим представлением и вашим условием where, только с первого представления
@ dwir182 на самом деле я беру некоторые столбцы из представления 1, а некоторые из представления 2. Для того, чтобы найти ошибку, я упростил запрос здесь. Мне нужны столбцы из второго представления, поэтому я присоединяюсь к представлению. Как вы можете видеть, это не создает никаких проблем, если я не помещаю предложение where.
@Snehal, извините, я запутался, когда увидел ваше присоединение, но не связанное с вашим выбором ..
Вы видите выполнение плана при выполнении запроса?
@ dwir182 не разбираюсь в плане выполнения. как я могу поделиться с вами?
это сложно, потому что это представление, поэтому оно может быть связано со многими таблицами. Вы должны показать свои определения представлений ..
"Я упростил запрос здесь". - возможно, упрощенно до такой степени, что нет очевидных проблем. Может помочь, если вы добавили полный запрос, определения представлений и определения базовых таблиц.
@Snehal brentozar.com/pastetheplan как XML
@IvanStarostin Спасибо за ссылку, но она поддерживает до 2 МБ. План XML превосходит это. Я не могу дать определение взгляда. а есть ли другой вариант?
нет, ты сам по себе.
Ответы 1
Мне кажется, что в столбце VoucherTypeCode нет индекса.
Если VoucherTypeCode является столбцом таблицы в вашей базе данных, вы можете попробовать проиндексировать этот столбец (см. Этот статья о создании индексов в MS Docs)
Если VoucherTypeCode является продуктом нескольких столбцов, вы можете попробовать проиндексировать само представление (см. Этот Статья об индексированных просмотрах на sqlshack.com)
В качестве альтернативы, если вы не можете / не хотите создавать индекс, ознакомьтесь с принятым ответом в этом StackOverflow-Thread
Индекс не всегда является решением проблемы Видеть это, а оп говорят with 80,000+ rows and 75+ columns и это большое ..
Я рекомендую индексировать VIEW_ITEM_STOCK_LEDGER с помощью VoucherTypeCode. Даже если вы используете только эти два типа ваучеров, вы можете использовать параметры фильтра индекса.
вместо условия where используйте условие where в join и проверьте скорость