Добрый день. Есть документ Протокол, к нему запрос

ВЫБРАТЬ
 Протокол.Ссылка,
 Протокол.НеИсполнен
ИЗ
 Документ.Протокол КАК Протокол
ГДЕ
 Протокол.Карта = &Карта
 И Протокол.НеИсполнен = ЛОЖЬ
 И Протокол.Вид В(&ВидыПротоколов)
 И Протокол.Проведен = ИСТИНА
 И Протокол.Дата <= &НаДату
УПОРЯДОЧИТЬ ПО
 Протокол.Дата

Индексы стоят на Карта, ранее стояли на НеИсполнен и Вид (но были убраны, так как на булево не рекомендуют, а Вид - до 1 тыс записей, тоже не рекомендуют. Но это не помогло)

Последнее время периодически данный простой запрос стал формироваться по 20 и более секунд, хотя обычно формировался 0,01сек. В выборке примерно 1-5 документов. Тормоза начинаются примерно в одно время когда пользователи начинают активно использовать данный запрос (пользователей 10-15).
Самое странное, если меняешь часть запроса, например, переставляешь местами условие, или добавляешь/убираешь поле в ВЫБРАТЬ, то запрос начинает формировать быстро, и после перезахода пользователей в программу все ОК. Но на след день все снова повторяется, и опять приходится чуток модифицировать запрос.

В(&ВидыПротоколов) - вот тут проблема

база серверная или файловая?

(2) серверная, объем большой данной таблицы, но в разрезе Карта - не так много записей (100-200)

(1) Виды протоколов - массив, обычно там 1 элемент, иногда чуть больше

(2)

Спорим он ответит - серверная.
Но ни имени sql-сервера, ни его версию не напишет ?
Обновляется ли статистка ?

(3) попробуй переделать на табл значений и внутреннее соединение

(5) Что там соединять? данные выбираются из одной таблицы.

(7) ВидыПротоколов это справочник?

ВЫБРАТЬ
Протокол.Ссылка
Поместить Протоколы
ИЗ
Документ.Протокол КАК Протокол

ГДЕ
Протокол.Карта = &Карта;

ВЫБРАТЬ
Протоколы.Ссылка,
Протоколы.Ссылка.НеИсполнен
ИЗ
Протоколы КАК Протоколы
ГДЕ
Протоколы.Ссылка.НеИсполнен = ЛОЖЬ
И Протоколы.Ссылка.Вид В(&ВидыПротоколов)
И Протоколы.Ссылка.Проведен = ИСТИНА
И Протоколы.Ссылка.Дата <= &НаДату
УПОРЯДОЧИТЬ ПО
Протоколы.Ссылка.Дата

Первым запросом выбрать по Карта и положить во временную таблицу. Вторым запросом наложить остальные условия

(9) точно так

(1)(3) если утверждения верны, то ВТ или вложенный запрос без этого условия исправят ситуацию

Оптимизатор не может решить, сканировать ли ему кластерный индекс или искать по некластерному с keylookup. Давайте поможем Даше.

(5) MS SQL 2012, статистика обновляется каждую неделю. Вроде как рекомендуют каждый день, переделаем

(9) Почему не выбрать нужные реквизиты в первом запросе? "Ссылка.<...>" режет глаза))

(9) Спасибо, понял идею.

(15) Потому что они не входят в некластерный индекс и за ними надо лезть в кластер, что соблазнит оптимизатор использовать кластер

(17) Я не про условия. Условие оставляем как есть, а в поля первого запроса добавляем нужные для отбора во втором.
Ну или уж заменить второй запрос на явное внутреннее соединение.

Описание из (0) похоже на то как будто не настроено обновление статистики. СУБД какая?

(14) раз в неделю при активной работе очень мало

(18) Ну тогда больше ненужных данных придется тянуть, т.к. нужна будет одна запись из двухсот.

(17) Правильно ли я понял , проблема в условиях
" И Протокол.Проведен = ИСТИНА
И Протокол.Дата <= &НаДату"

Скуль сначала кластер смотрит?

(18) "а в поля первого запроса добавляем нужные для отбора во втором"

Откуда SQL добудет эти поля?

(22) Нет. Проблема и в условиях и в полях, которых нет в некластерном индексе "Протокол.Карта", и поэтому SQL предпочитает его, этот некластерный индекс не использовать, как только статистика начинает устаревать.

Старайтесь думать, как SQL

кстати, буквально на днях обновили
https://its.1c.ru/db/metod8dev/content/1590/hdoc

(0) Забыл еще добавить, Карта - реквизит составного типа (2 справочника)

(23) из таблицы документа. Бывает по-другому? В твоем случае SQL возьмет данные только из индекса без обращения к основной таблице?

(21) Что значит ненужных, они нужны для последующего отбора? Выбрать три колонки в по 100-200 документам явно эффективнее чем ещё одно левое соединение во втором запросе... или не эффективнее по причинам указанным в (15).

Было бы на чем проверить, у меня эти утверждения вызывают сомнения.

(28) Если SQL возьмет эти поля из таблицы документа - это может склонит его использовать таблицу документа для поиска, не лезя в индекс, как было в исходном запросе.
Поэтому мы будем оперировать только с полями, которые есть в индексе, отберем по нему 10-20 записей. А потом 2-м запросом вытащим левым соединением эти поля для 10-20 записей из таблицы данных.

(30) Для меня само утверждение, что SQL может использовать только таблицу индекса без обращения основной таблице, несколько неожиданно. Отсюда сомнения.

А неявное левое соединение в условиях с наложением условия на правую таблицу вызывает возмущение)) Не исключаю, что это реально работает, но на первый взгляд выглядит дико.

(0) Готов затестить пару-тройку запросов?

Не понимаю какого хрена спорите о неких индексах
Когда у ТС явные проблемы многозадачности и возможно блокировок

Выполнение 1 запроса монопольно
И одновременно 10-15 этих же запросов параллельно
Да еще возможно когда в табличку пишут - накладывается блокировка на чтение

(31) Может, даже добавили возможность настраивать в 1С Корп
https://wonderland.v8.1c.ru/blog/povyshenie-gibkosti-nastroyki-indeksov/

(34) 1С здесь вроде вообще не при чём, это же всё внутри SQL.

(0) в запросе нет проблем, похоже что-то с базой - либо документов много слишком!!! тогда да... будет висеть

(35) по ссылке из (34) если вытаскиваешь запросом Поставщик + Валюта, то используется индексная таблица. Чтобы не обращаться к основной таблице за данными "Склад" и "Организация" добавили возможность их дополнять.
Раньше такого не было, так что 1С еще как причем.

(34) в КОРП 8.3.27 уже добавили

(33) На проведение документов пользователи не жаловались, ошибок блокировок не видел, ручные блокировки не используем

(39) здесь явное непопадание в индекс, думаю ВТ решит проблему

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

(41) Стеб? Сам был удивлен, что перестановка условий влияет на скорость выполнение запроса, вот и спрашиваю у коллективного разума 1Сников, как такое может быть

(42) SQL запомнил что с таким запросом ему будет лучше прочитать всю физическую таблицу без индексов.
Пришел другой запрос, глянул в статистику - воспользовался таблицей индексов. Запомнил на будущее, что новый запрос идет с индексами. И тд

В общем, профайлер надо смотреть в MSSQL

(42) Такое не может быть
Есть дополнительные внешние влияющие факторы

Например табличка индексов слишком занята другими параллельными запросами а физическая таблица без индексов нет - и СУБД решила сканить ее или другие таблички индексов сначала а затем вернуться к первой

(45)+ А когда перестает тормозить - вероятно помогает выгон пользователей и остановка/очистка очереди запросов скуля

(45) А может просто кеш

(46) Я прямо в консоле отчетов корректирую запрос, пользователей не выгоняя. С одним текстом быстро, с другим долго

(48) Ну так логично, когда с другим долго - его сейчас юзают другие юзеры например

(42) При перестановке получается, по сути, новый запрос под который генерится новый план, который может быть удачнее старого. Тут уже планы надо бы вытаскивать и сравнивать чтоб понять почему.

(45) Нет, субд не анализируют текущую занятость индексов запросами. Во всяком случае, mssql и postgres точно так не делают