Вводные данные:
Платформа 8.2.18.109, SQL 2008 standard
SQL-ю выделено 320 Гб ОЗУ, база на SSD, с проведением документов проблем нет.

Простая форма списка документов (Реализация товаров) и журнала (Реализации и возвраты).
При листании списка иногда возникают тормоза по 1.5-2 секунды на страницу (PgUp/PgDown).

Размеры таблиц:
_Document240 (шапка реализаций) - 40Гб (8 млн. документов, всё лишнее удалено)
_DocumentJournal7838 - смешные 8Гб.


Профайлер показывает большой Duration на запросе:

SELECT TOP 51
_Document240_R._Date_Time AS _A1,
_Document240_R._Number AS _A2,
_Document240_R._Fld6451 AS _A3,
_Document240_R._IDRRef AS _A4RRef,
_Document240_R._Marked AS _A5,
_Document240_R._Posted AS _A6,
_Document240_R._Fld6439RRef AS _A7RRef
FROM
_Document240 _Document240_R WITH(NOLOCK)
WHERE
_Document240_R._IDRRef > P1 AND _Document240_R._Date_Time = @P2 AND _Document240_R._Date_Time >= @P3 AND _Document240_R._Date_Time <= @P4 OR
_Document240_R._Date_Time > @P5 AND _Document240_R._Date_Time >= @P6 AND _Document240_R._Date_Time <= @P7
ORDER BY
_Document240_R._Date_Time,
_Document240_R._IDRRef

план запроса
https://yadi.sk/i/dR_S9q0z3PDPuL




Аналогичная картина с журналом документов (реализации и возвраты вместе):

SELECT TOP 48
_DocumentJournal7838_R._Date_Time AS _A1,
_DocumentJournal7838_R._Number AS _A2,
_DocumentJournal7838_R._Fld7841 AS _A3,
_DocumentJournal7838_R._DocumentTRef AS _A4TRef,
_DocumentJournal7838_R._DocumentRRef AS _A4RRef,
_DocumentJournal7838_R._Marked AS _A5,
_DocumentJournal7838_R._Posted AS _A6
FROM
_DocumentJournal7838 _DocumentJournal7838_R WITH(NOLOCK)
WHERE
_DocumentJournal7838_R._DocumentRRef > P1 AND _DocumentJournal7838_R._Date_Time = @P2 AND _DocumentJournal7838_R._DocumentTRef = @P3 AND _DocumentJournal7838_R._Date_Time >= @P4 AND _DocumentJournal7838_R._Date_Time <= @P5 OR
_DocumentJournal7838_R._DocumentTRef > @P6 AND _DocumentJournal7838_R._Date_Time = @P7 AND _DocumentJournal7838_R._Date_Time >= @P8 AND _DocumentJournal7838_R._Date_Time <= @P9 OR
_DocumentJournal7838_R._Date_Time > P10 AND _DocumentJournal7838_R._Date_Time >= P11 AND _DocumentJournal7838_R._Date_Time <= P12
ORDER BY
_DocumentJournal7838_R._Date_Time,
_DocumentJournal7838_R._DocumentTRef,
_DocumentJournal7838_R._DocumentRRef

план запроса
https://yadi.sk/i/hvoQh2RU3PDPrH



Что можно подкрутить в SQL, чтоб он листал быстрее?

Иногда запрос может выполняться по разным планам...
Лови момент притормаживания.

(0) Точно этот запрос тормозит? У нас 80% времени занимал вывод картинки "Ручная корректировка" в списке. Заменил тот бред, который был в типовой (УТП для Казахстана), на свой бред - список стал летать

(0) попробуй установить фильтр с начала года.
у нас тоже были подобные "жалобы" -"копирование ПП тупиииит" (с) пользователь
на самом деле после копирования пользователь вываливался в список ПП с 2010 года на последнее.
фильтр по дате с начала года. использовать по умолчанию - просто взбодрило процесс до 1-2сек)

(2) Да, смотрю duration в профайлере.
(3) Если листать "с конца" - все летает. Если поставить интервал 2017 год и листать с начала года - тормоза.
При реальной работе ситуации разные - может в разные моменты тормозить.
Я так понимаю, что в случае с журналом - чистый "индекс скан" работает, и очень долго, хотя размер таблицы относительно небольшой. Вот что странно.

ночью сделай перестройку индексов,

ps
ну и про обновление статистики даже не спрашиваю

(5) Делал - и перестройку индексов, и статистику обновлял.

(0) А если избавиться от OR в запросе?

(7) Хорошо пошутил :)
Это журнал - запрос платформа генерит

покажи поля и их индексы в структуре таблице

_Document240_R._IDRRef
_DocumentJournal7838_R._Date_Time

(8) Ага, а запрос дин. списка можешь скинуть?
И его же настройки

Очередь к диску смотри, а не длительность запросов

вообще такое будет например если кто-то игрался с пермишекей

ну и кстати

заходишь в базу, находишь таблицу в ней есть вкладка "статистика" (правда на старых скулях не помню, может и нет ее), там должна быть статистика которая попадает в индекс (внутри поля строго по порядку как в запросе), чем больше совпало - тем выше вероятность попадания в индекс

поля такие

1. _IDRRef
2. _Date_Time

а на сколько я понимаю реальные индесы идут наоборот

1. _Date_Time
2. _IDRRef

то есть у тебя не хватает индекса _Date_Time + _IDRRef хотя наверно есть индекс _IDRRef + _Date_Time но он не работает

(12) "пермишекей" - что это за х..ня?

(12) ну тут в запросе только даты фигурируют. ограничений по фирмам нет.

(13) вроде MS SQL не требует порядка полей в запросе и порядка в индексе. оптимизатор по сообразительней. сам перестраивает запрос.
если же нет - значит формочка уже руками потроганная) и привет MS SQLю
руками индекс создавать.
сейчас глянул в УПП реализация - индекс
_Document..._ByDocDate
_Date_Time, _IDRRef, _Marked

(14) rls

А что менялось до и после торомзов в базе? Может у вас план обсулживания по обновлению статиски полетел. Динамический список не запросный? Выводится таблица? кто что менял ищите

(16) Формы - обычные, в заголовке указал. Обычный "ЖурналДокументовСписок".

(9) Индексы
_Documen240_ByDocDate_TR:
_Date_Time, _IDRRef


_Docume7838_ByDocDate_TR
_Date_Time, _DocumentTRef,_DocumentRRef    


Закладки "статистика" нет.

(16) Да хз когда тормоза появились, просто раньше внимания не обращал.

RLS - нет, смотрю под полными правами.

(18)
индекса содержащего _IDRRef, _Date_Time нет в наличии на табличке?


фигня какаято. первый запрос сваливается в перебор.
либо статистика отпала нафиг.
либо индекса нет и тии надо делать. либо и не было его никогда)

а что за конфигурация такая интересная?

(19) По "_IDRRef" - только кластеризованный.
Отдельного "_IDRRef, _Date_Time " - нет.

"либо статистика отпала нафиг." - и как её вернуть?
update statistics делал.

Как конфигурация может повлиять на индексы? Только на дополнительные разве что. БП 1.6 старенькая дописанная.

(0)

В первом случае в индексе документа _Document240_R нет поля _Fld6439RRef AS _A7RRef, и из-за этого СУБД ищет его в кластерном индексе. В вашем случае, чтобы устранить замедление в первом запросе, нужно либо убрать это поле из запроса, либо каким-то образом переписать запрос/изменить структуру (как пример сходу, хранить это поле в регистре сведений).

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

(21) А и так из форм списка для выложенных запросов убрал всё что можно и что нельзя, на самом деле нужных полей намного больше.
Т.е. на "индекс скан" мы обречены?

http://catalog.mista.ru/public/128175/

(23) если строго - это нарушение лицензионного соглашения.

(24) нет, не нарушение....

(25) нет, нарушение

(0) на событии "ПриВыводеСтроки" запросы не формируются?

(26) профиль поправь

(25)Лицензиат обязуется не допускать нарушений исключительных прав Правообладателя на ПРОГРАММНЫЙ ПРОДУКТ, в частности, не совершать и не допускать совершения третьими лицами следующих действий без специального письменного разрешения Правообладателя:
......................................................
вносить какие-либо изменения в код ПРОГРАММНОГО ПРОДУКТА, содержимое баз данных и других наборов данных, в которых система хранит информацию, за исключением тех изменений, которые вносятся штатными средствами, входящими в состав ПРОГРАММНОГО ПРОДУКТА и описанными в сопроводительной документации;

v8: Лицензионное соглашение

Я понимаю что это несколько напрягает, но... договор есть договор

(28) а с текущим что не так?

(0) Покажи оригинальный запрос 1с

(30) ты не  Кмр

Меня лично смущают эти странные условия
_DocumentJournal7838_R._DocumentRRef > P1 AND _DocumentJournal7838_R._Date_Time = @P2 AND _DocumentJournal7838_R._DocumentTRef = @P3 AND _DocumentJournal7838_R._Date_Time >= @P4 AND _DocumentJournal7838_R._Date_Time <= @P5

(25),(26)метод определения нарушается соглашение или нет такой:
если после выгрузки-загрузки через *.DT в базе ничего не изменится - это не нарушение, иначе нарушение.
пример флаг max degree parallelism - не слетит при такой операции - НЕ нарушение,
индексы слетят - нарушение

(31) Листаю журнал или список документов. Всё. Никакого объекта "Запрос" - не создается.

Если кто-нибудь в обычных формах 8.2 сможет показать свой план запроса при листании списка документов - буду благодарен.

(34) А если эти индексы будет восстанавливать ALL SERVER триггер, то это перестанет быть нарушением?

(29),(34) Ответственность не предусмотрена.

(0)нет покрывающего индекса.
Т.е. ты выбираешь поля из документа (но отбор по дате), которых нет в составе индекса по дате.

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

Затем выбирать запросом из этого регистра.
Вариант_2: Добавить в индекс по дате - все необходимые поля выборки в MS SQL Server. В этом есть минус - следующее обновление конфигурации твой индекс уберет.

(29) (26) читаем

Гражданский кодекс РФ от 18.12.2006 N 230-ФЗ - Часть 4 Статья 1280. Свободное воспроизведение программ для ЭВМ и баз данных.

(29) "которые вносятся штатными средствами, входящими в состав ПРОГРАММНОГО ПРОДУКТА и описанными в сопроводительной документации;"
Так то MS SQL server + SSMS - входят в состав программного продукта. Вы еще softpoint пож это подведите.

(0)Решение проблемы в данном случае сводится к тому, чтобы создать хранение данных наподобие аля-кластерный индекс "по дате"

(40) (41) спросите это у представителей 1С - узнаете много нового.

(41) >Так то MS SQL server + SSMS

не являются ни штатным ни заштатным продуктом фирмы 1С

про софтпоинт опять-же уточняйте в фирме 1С - у них может быть спецсоглашение

(29) Тогда на ИТС зачем мануалы написаны

https://its.1c.ru/db/metod8dev#content:5837:hdoc:p4

(45) Кстати да. (43) короче твое айяйяй только у тебя в голове.

(39) Я оставил самый минимум: номер и дату. Сделал покрывающий индекс (через "помощника настройки ядра СУБД" - подсунул ему этот запрос). Один черт - индекс скан по этому индексу, скорость такая же.
https://yadi.sk/i/T-kBh5s73PENoR

Видимо, sql не может переварить запрос с такой кучей условий на даты, который генерит список документов.

(48) так оптимизатор заработает по новому индексу только после сброса статистики

(46) не приятгивайте за уши методологию обслуживания БД с вмешательством в структуру Б

Б= ИБ

(48) 1802 это Duration?

(50) и чистки процедурного кэша... и да, дефрагментацию давно выполняли?

(45) мануалы написаны по сопровождению СУБД, а не об изменении физической сущности базы НЕ средствами эсочки. Грубо говоря, если вы покупаете УТ, вставляете триггер, где при инсёрте нового элемента номенклатуры реиндексируете всю базу, а потом жалуетесь в компанию 1С, что их программа тормозит и г*вно, то 1С в свою очередь может вас послать (и обязательно пошлёт).

(48)Видимо из статистических данных MSSQL решил что так будет оптимальнее...(На выполнение запроса может повлиять и статистика)

(0) рлс исключил? под полными правами тож торомзит? создай обработку, сделай в ней форму списка журнала документов. Что за привычка сразу в профайлер лезть?

(17) Попробуйте перевести этот список на управляемые. Планы обслуживания на скуле смотрели?

SELECT TOP 51

это динамический запрос что ль? что вообще за программа?

(57) в профайлере запрос с учетом рлс, тебе ли этого не знать

(60) видимо запрос динамического списка

а в результате окажется, что на форме есть какой либо текстовый реквизит, который получает значение из текущей строки списка, таща на клиента весь объект целиком

(62) (63) как я понял у автора ОБЫЧНЫЕ формы

(57) рельсы тут нет, это видно по запросу... рельса ВСЕГДА выполняется внутри ХП...

(0)RLS?

(53) Да, он.
(63) Причем тут форма, если есть конкретный запрос SQL с duration 1800?
(66) С RLS запрос выглядел бы совсем по-другому.

(67) кстати вопрос:

SQL на виртуалке?

(67) 1800- это же 1.8мс, долго ?

(69) Duration в миллисекундах, это 1,8 сек

(70) разве ? А не в микросекундах ?

не помню ужо

(68) Нет конечно.

(67) можно текстовый план запроса?

Не вижу плана почему-то (что-то с Яндексом). Так что там с индексом, поясните кто вкурил? Индекс по дате+ссылке должен быть стандартный у всех доков, предназначен именно для списков. Чтобы при запросе дин. списка скуль пошел не по этому индексу, это нужно очень постараться.

Может сортировка в списке не та? Может нужно сделать ТИИ с реиндексацией?

в свойствах базы смотри все параметры типа

"Автоматическое обновление статистики" и прочее связанные со статистикой...

зы
мне кажется, что дело именно в статистике

(70) Сервер сообщает о длительности события в микросекундах (10^-6 с), а о количестве времени, затраченного ЦП на событие, в миллисекундах (10^-3 с). В Приложение SQL Server Profiler графический пользовательский интерфейс по умолчанию отображает столбец Продолжительность в миллисекундах, но, когда данные трассировки сохраняются в файле или таблице базы данных, значение столбца Продолжительность записывается в микросекундах.

https://docs.microsoft.com/ru-ru/sql/tools/sql-server-profiler/view-and-analyze-traces-with-sql-server-profiler

(74) Наконец снова добрался до базы.
Вот план запроса из технологического журнала:
0, 1, 47, 0, 4.7E-006, 76, 0.00733, 1,   |--Top(TOP EXPRESSION:((47)))
0, 1, 47, 202, 6.31, 76, 0.0069, 1,        |--Clustered Index Scan(OBJECT:([test_copy].[dbo].[_DocumentJournal7838].[_Docume7838_ByDocDate_TR] AS [_DocumentJournal7838_R]),  WHERE:([test_copy].[dbo].[_DocumentJournal7838].[_DocumentRRef] as [_DocumentJournal7838_R].[_DocumentRRef]>[@P1] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]=[@P2] AND [test_copy].[dbo].[_DocumentJournal7838].[_DocumentTRef] as [_DocumentJournal7838_R].[_DocumentTRef]=[@P3] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]>=[@P4] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]<=[@P5] OR [test_copy].[dbo].[_DocumentJournal7838].[_DocumentTRef] as [_DocumentJournal7838_R].[_DocumentTRef]>[@P6] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]=[@P7] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]>=[@P8] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]<=[@P9] OR [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]>[@P10] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]>=[@P11] AND [test_copy].[dbo].[_DocumentJournal7838].[_Date_Time] as [_DocumentJournal7838_R].[_Date_Time]<=[@P12]) ORDERED FORWARD)

Т.е. Clustered Index Scan - и всё. И это медленно.

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

(78) Clustered Index Scan и должен быть. План нормальный. Странно, что медленно. статистику по I/O бы глянуть...

Может все-таки переиндексировать? Кто в курсе, при ТИИ кластерные индексы пересоздаются?

(80) Переиндексировал, и через 1С реструктуризировал журнал (когда графы меняешь).
Я бы согласился, что нормально, но когда снизу вверх листаешь - всё намного быстрее :(

(79) А какая графа тут время отображает? И в каких единицах?

(81) Со стороны 1С все норм, проблема в скуле имхо. Или в конкретной базе.

(81) Раз уж тронул журнал, попробуй из состава доки убрать, чтоб он очистился. А потом вернуть.

(0) в обеих списках в запросе нету поля description, при выводе на каждую строку идут обращения к sql?

(78) при --Top(TOP EXPRESSION:((47)))  всегда будет скан это самое быстро что можно сделать

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

Думаю, после праздников проблема сама собою рассосется

(78) какое-то дикое условие
попробовал на своем журнале (отбор по периоду установлен, видимость ссылочных колонок отключена):

WHERE ((T1._Date_Time >= P1) AND (T1._Date_Time <= @P2)) AND T1._Date_Time = @P3 AND T1._DocumentTRef = @P4 AND T1._DocumentRRef > @P5

Откуда у тебя остальные условия берутся, вообще непонятно.

Пробуй, как уже сказали, ЖурналСписок в новой, пустой форме. Интересно, дин. список какой запрос сформирует.
На крайний, журнал всегда можно заэмулировать через РС.

http://catalog.mista.ru/public/421684/

(0)
Полагаю, что у автора все регламенты, статистика/индексы обновляются.

Попробую в настройках списка вообще установить полные стандартные настройки. Вообще снять сортировку любого рода.

очень помагает еще использование последней платформы

советую использовать 8.3

(89) Там не один запрос идет, а несколько. Ты полистай туда-сюда.

Я может где-то пропустил это же УФ или обычная форма?

(94) Ну да. Параметры меняются.

(90) >проблемы в операторе ORDER BY,  который платформа сама старательно добавляет, и неважно, что сортировка вообще пользователем не указана
>Осталось только ждать и надеяться, что 1С все-таки согласится исправить такое поведение ДС

Вывод автор статьи сделал неверный. Без ORDER BY не будет никакого ДС. Важно, чтобы этот ORDER BY попадал в индекс и не требовал доп. сортировки. В остальном статья норм.

(96) Не только параметры, но и сами запросы. Просто задумайся над условием "_Date_Time = @P3"

(97) спорно. и можем много спорить. Ест-но что без сортировки не будет ДС. Но как ведомо сортировка отжирает весомый процент.

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

а поиск ключа если я не ошибаюсь происходит в случае, когда выводятся колонки которые вне индекса.

В этом запросе я непонял зачем дважды выводиться одна и таже ссылка?

_DocumentJournal7838_R._DocumentTRef AS _A4TRef,
_DocumentJournal7838_R._DocumentRRef AS _A4RRef,

И вот:
ORDER BY
_DocumentJournal7838_R._Date_Time,
_DocumentJournal7838_R._DocumentTRef,
_DocumentJournal7838_R._DocumentRRef

у вас, что там соединения с ТЧ какие-то?

(100) "Поиск ключа" это key lookup что ли? Некорректный перевод, это "поиск по ключу".

У автора статьи ситуация другая. У него запрос к таблице документа, там индекс по дате некластерный, а данные тянутся из кластерного, из-за этого большая трудоемкость. Тут же индекс на журнале кластерный, поэтому никаких key lookup, ничего лишнего, Index scan + top. Но почему-то медленно. Нужно смотреть статистику.

(102) Это тип + ссылка (TRef + RRef)

(78) Т.е. Clustered Index Scan - и всё. И это медленно.

Скан это плохо. Это значит, что он проходит таблицу сканируя. А вдолжен быть SEEK

Явно говорит о том, что нет покрытия полей в индексе

https://its.1c.ru/db/metod8dev#content:1590:hdoc

Ссылка - кластерный индекс всегда

[ОРРХ | ОРНР1 +] Дата + Ссылка

ДС и делает сортировку по дати и ссылке поскольку полагается, что это кластерный индекс

(106) в выборе первых записей будет всегда скан, и он не сканирует всю таблицу он выбирает только первые 50 записей

(111) в данном случае согласен поскольку испльзуется ключевое ТОР

(98) >>Просто задумайся над условием "_Date_Time = @P3"

Задумывался))
Сейчас вижу, что два запроса выполняется, один с "AND T3._Date_Time > @P3" (если листать вверх, то < @P3, что логично).
Второй уже, видимо, строится по результатам первого, с "_Date_Time = @P3 AND T2._DocumentTRef < @P4"

В обоих случаях - Index Seek,  ничего похожего на монструозное условие ТС нет.

(113) ввобще-то ДС при первом открытии имеет один вид запроса. А поотм другой. Это сделано для того-чтобы поймать курсор.

Но автору я бы настоятельно рекомендовал обновить платформу.

(0) Автор почитай что сделали в платформе 8.3.10 там большой уклон пошол на оптимизацию и ускорения работы и очень много работы на ДС припало.

кстати это микросекунды же, у меня в профайлере в микросекундах указывается. 1400 это вообще мизер тогда и проблема не в запросах.

ну и нету здесь decription как тогда ссылочной тип на форму попадает? в sql должно быть много доп запросов на вывод строк. этого не видно в том что дали.

Забили - автора давно нет тут!

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

(116) не факт, это настраиваемый параметр (милли или микро)

(119) Зачем? У меня все нормально))

(121) Интересно сравнить с ТС

(122) https://pastebin.com/EWuqFDyx

(123) +
8.2.19.106
Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64)

(123) Сейчас уточнил в BOL. INDEX SCAN это полный просмотр индекса, а INDEX SEEK - поиск по ключу. (Я привык к оракловой терминологии, где scan обозначает и то и другое.)

https://technet.microsoft.com/en-us/library/ms175184(v=sql.105).aspx
https://technet.microsoft.com/en-us/library/ms190400(v=sql.105).aspx

Так что почти все стало ясно у ТС. Скуль выбирает scan, скорее всего из-за двух OR в условии. Вместо того, чтобы сделать три раза seek и сортировку. Может, и кривая статистика вносит свой вклад.

Откуда там взялись эти OR, остается интересным.

про покрывающий индекс уже было?

вообще у автора ожидание page latch, поднятие страниц с диска есть?

(125) ну да с чего бы? он скан делает потому что индекса покрывающего нет по предикату

(78) всё-же сделайте как написано в (79) и ещё кроме того, попробуйте  кликнуть по колонке Дата что-бы отсортировались документы по дате и посмотрите что после этого будет со скоростью.

(125) он не сканирует всю таблицы, у него есть TOP в запросе. Он просто отбирает 50 записей сканом  и все...

(130) Ага. Это так, если нет условия в запросе.

(131) это всегда так. В первом запросе вложенные циклы выполнялись только 51 раз, а не скан с поиском ключа и  потом выбор 51 строки. В планах нету  sort. Значит он попал в индекс по сортировки.

(93) Это не так просто. Пока 8.2 в режиме совместимости 8.1. Переходить на 8.3 (даже только смена платформы) - к тому времени или ишак, или эмир :)
(95) Всё обычное (см.заголовок).
Уточню: при листании последнего месяца - по 10 страниц в секунду пролетает.
При листании января - на каждый PgDown уходит больше секунды.

(129) После праздников попробую сортировать туда-сюда. А права и так полные.

Наблюдаю.
Особенно тех кто заявляет "вы не умеете её готовить"
Посмотрим...
Интересно.

(128) Все поля из предикатов есть в индексе. Индекс кластерный, так что все остальное там тоже есть, по определению.

(130) >Он просто отбирает 50 записей сканом  и все...
А какие именно 50 записей, из какого места? Ты физическую структуру индекса немного представляешь себе?

(133)  главеое сделай пустую форму чтоб ни строчки кода

(0) Какой период в списке? Попробуйте установить минимальный период например Текущий день.

Возможно у вас в спике используется такие понятия как ПриАктивизацииЯчейки, приПолученииДанных и т.д. Есть ли в списке вообще другие обработчики, этот список Чист без разных обработчиков?

сделать ТиИ - одна из рекомендаций ИТС. Но мне не нравиться, что конфа вообще в совместимости 8.1

(133) Я думаю многие оптимизаторы со мною согласятся - вот все работало прекрасно и замечательно и бах...

Это все проблемы так начинаются. И тут проблематика в данном случае если у Вас вообще "Чистый список" без лишнего кода при обработке данных например на лету. И Вы начинаете вот так висеть. Индексы перестроены, статистика не помогает, ТиИ тоже, диски крутые и все точка.

В данном контексте у вас 8.2 да еще на совместимости с 8.1 тоже не айс. Я уже молчу о взаимоблокировках.

(136) В форме закомментирован весь код.
Вот видео, где листаю страницами: видно, что тормозит январь, а октябрь - летает.
https://youtu.be/iju8hUr95FY
(139) Про взаимоблокировки я бы поспорил. Правильные управляемые блокировки уже в 8.1 рулят и педалят в самописках.
"вот все работало прекрасно и замечательно и бах... " - такого не было. Просто количество документов перешло в качество.

(140) Попробуй, ради интереса, еще сделать обработку, в ней УФ, в УФ - дин. список с этим журналом. Какой там запрос будет генериться.
Вроде бы УФ открывается даже в режиме совместимости 81, если не внешняя.

Продолжаю с интересом наблюдать. Где же все специалисты, которые умеют её готовить?

Как и ожидалось, дело оказалось в платформе 1С.
Убрал режим совместимости 8.1 (платформу не менял, та же 8.2, обычные формы): сразу поменялся текст запроса к СУБД, и план запроса превратился в Clustered Index Seek.

Запрос стал такой:
SELECT TOP 43
T2._Date_Time,
T2._Fld7841,
T2._DocumentTRef,
T2._DocumentRRef,
T2._Marked,
T2._Posted
FROM _DocumentJournal7838 T2 WITH(NOLOCK)
WHERE ((T2._Date_Time >= P1) AND (T2._Date_Time <= @P2)) AND T2._Date_Time = @P3 AND T2._DocumentTRef > @P4
ORDER BY (T2._Date_Time) ASC, (T2._DocumentTRef) ASC, (T2._DocumentRRef) ASC
OPTION (FAST 1)

Кстати, модный "динамический список" в управляемой форме - тормоз страшный. До "ЖурналДокументовСписок" - ему не дотянуться.

(144) Кстати иметь овно конфигурацию в режиме совместимости 8.1 при этом платформа даже не 8.3 умозаключение МЕЛКОЕ!

(144) Модный динамический список иногда незаменим.

(144) идея дин.списка что вы возвращаете только то что вам нужно, начните с того что - уберите лищние колонки