Вход | Регистрация

  1  2   
1С:Предприятие ::

Метки:

Спецам SQL. Тормоза в списке документов (обычные формы, 8.2, SQL)

Я
   ptiz
 
30.10.17 - 10:38
Вводные данные:
Платформа 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, чтоб он листал быстрее?
 
  Рекламное место пустует
   АНДР
 
1 - 30.10.17 - 10:51
Иногда запрос может выполняться по разным планам...
Лови момент притормаживания.
   Сти
 
2 - 30.10.17 - 11:04
(0) Точно этот запрос тормозит? У нас 80% времени занимал вывод картинки "Ручная корректировка" в списке. Заменил тот бред, который был в типовой (УТП для Казахстана), на свой бред - список стал летать
   ИмяФамилия
 
3 - 30.10.17 - 11:16
(0) попробуй установить фильтр с начала года.
у нас тоже были подобные "жалобы" -"копирование ПП тупиииит" (с) пользователь
на самом деле после копирования пользователь вываливался в список ПП с 2010 года на последнее.
фильтр по дате с начала года. использовать по умолчанию - просто взбодрило процесс до 1-2сек)
   ptiz
 
4 - 30.10.17 - 11:20
(2) Да, смотрю duration в профайлере.
(3) Если листать "с конца" - все летает. Если поставить интервал 2017 год и листать с начала года - тормоза.
При реальной работе ситуации разные - может в разные моменты тормозить.
Я так понимаю, что в случае с журналом - чистый "индекс скан" работает, и очень долго, хотя размер таблицы относительно небольшой. Вот что странно.
   vde69
 
5 - 30.10.17 - 11:27
ночью сделай перестройку индексов,

ps
ну и про обновление статистики даже не спрашиваю
   ptiz
 
6 - 30.10.17 - 11:44
(5) Делал - и перестройку индексов, и статистику обновлял.
   xXeNoNx
 
7 - 30.10.17 - 11:49
(0) А если избавиться от OR в запросе?
   ptiz
 
8 - 30.10.17 - 11:51
(7) Хорошо пошутил :)
Это журнал - запрос платформа генерит
   vde69
 
9 - 30.10.17 - 11:51
покажи поля и их индексы в структуре таблице

_Document240_R._IDRRef
_DocumentJournal7838_R._Date_Time
   xXeNoNx
 
10 - 30.10.17 - 11:52
(8) Ага, а запрос дин. списка можешь скинуть?
И его же настройки
 
  Рекламное место пустует
   Cyberhawk
 
11 - 30.10.17 - 11:52
Очередь к диску смотри, а не длительность запросов
   vde69
 
12 - 30.10.17 - 11:55
вообще такое будет например если кто-то игрался с пермишекей
   vde69
 
13 - 30.10.17 - 12:04
ну и кстати

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

поля такие
1. _IDRRef 
2. _Date_Time 

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

1. _Date_Time
2. _IDRRef

то есть у тебя не хватает индекса _Date_Time + _IDRRef хотя наверно есть индекс _IDRRef + _Date_Time но он не работает
   nicxxx
 
14 - 30.10.17 - 12:10
(12) "пермишекей" - что это за х..ня?
   ИмяФамилия
 
15 - 30.10.17 - 12:10
(12) ну тут в запросе только даты фигурируют. ограничений по фирмам нет.

(13) вроде MS SQL не требует порядка полей в запросе и порядка в индексе. оптимизатор по сообразительней. сам перестраивает запрос.
если же нет - значит формочка уже руками потроганная) и привет MS SQLю
руками индекс создавать.
сейчас глянул в УПП реализация - индекс
_Document..._ByDocDate
_Date_Time, _IDRRef, _Marked
(14) rls
   breezee
 
16 - 30.10.17 - 12:12
А что менялось до и после торомзов в базе? Может у вас план обсулживания по обновлению статиски полетел. Динамический список не запросный? Выводится таблица? кто что менял ищите
   ptiz
 
17 - 30.10.17 - 12:16
(16) Формы - обычные, в заголовке указал. Обычный "ЖурналДокументовСписок".
   ptiz
 
18 - 30.10.17 - 12:25
(9) Индексы
_Documen240_ByDocDate_TR:
_Date_Time, _IDRRef


_Docume7838_ByDocDate_TR
_Date_Time, _DocumentTRef,_DocumentRRef    


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

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

RLS - нет, смотрю под полными правами.
   ИмяФамилия
 
19 - 30.10.17 - 12:33
(18)
индекса содержащего _IDRRef, _Date_Time нет в наличии на табличке?


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

а что за конфигурация такая интересная?
   ptiz
 
20 - 30.10.17 - 12:43
(19) По "_IDRRef" - только кластеризованный.
Отдельного "_IDRRef, _Date_Time " - нет.

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

Как конфигурация может повлиять на индексы? Только на дополнительные разве что. БП 1.6 старенькая дописанная.
   Elatiell
 
21 - 30.10.17 - 12:58
(0)

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

Во-втором запросе из-за того, что слишком много полей, которые наверняка не нужны пользователям, СУБД не остается других вариантов, кроме как сканить всю таблицу. Уберите лишнее.
   ptiz
 
22 - 30.10.17 - 13:05
(21) А и так из форм списка для выложенных запросов убрал всё что можно и что нельзя, на самом деле нужных полей намного больше.
Т.е. на "индекс скан" мы обречены?
   vde69
 
23 - 30.10.17 - 13:11
   rphosts
 
24 - 30.10.17 - 13:28
(23) если строго - это нарушение лицензионного соглашения.
   vde69
 
25 - 30.10.17 - 13:46
(24) нет, не нарушение....
   alkorolev
 
26 - 30.10.17 - 15:06
(25) нет, нарушение
   alkorolev
 
27 - 30.10.17 - 15:07
(0) на событии "ПриВыводеСтроки" запросы не формируются?
   rphosts
 
28 - 30.10.17 - 15:18
(26) профиль поправь
   rphosts
 
29 - 30.10.17 - 15:24
(25)Лицензиат обязуется не допускать нарушений исключительных прав Правообладателя на ПРОГРАММНЫЙ ПРОДУКТ, в частности, не совершать и не допускать совершения третьими лицами следующих действий без специального письменного разрешения Правообладателя:
......................................................
вносить какие-либо изменения в код ПРОГРАММНОГО ПРОДУКТА, содержимое баз данных и других наборов данных, в которых система хранит информацию, за исключением тех изменений, которые вносятся штатными средствами, входящими в состав ПРОГРАММНОГО ПРОДУКТА и описанными в сопроводительной документации;

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

Я понимаю что это несколько напрягает, но... договор есть договор
   alkorolev
 
30 - 30.10.17 - 15:28
(28) а с текущим что не так?
   AlfaDog
 
31 - 30.10.17 - 15:32
(0) Покажи оригинальный запрос 1с
   rphosts
 
32 - 30.10.17 - 15:32
(30) ты не  Кмр
   AlfaDog
 
33 - 30.10.17 - 15:34
Меня лично смущают эти странные условия
_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
 
  Рекламное место пустует
   Timon1405
 
34 - 30.10.17 - 15:38
(25),(26)метод определения нарушается соглашение или нет такой:
если после выгрузки-загрузки через *.DT в базе ничего не изменится - это не нарушение, иначе нарушение.
пример флаг max degree parallelism - не слетит при такой операции - НЕ нарушение,
индексы слетят - нарушение
   ptiz
 
35 - 30.10.17 - 15:40
(31) Листаю журнал или список документов. Всё. Никакого объекта "Запрос" - не создается.
   ptiz
 
36 - 30.10.17 - 15:42
Если кто-нибудь в обычных формах 8.2 сможет показать свой план запроса при листании списка документов - буду благодарен.
   MM
 
37 - 30.10.17 - 15:51
(34) А если эти индексы будет восстанавливать ALL SERVER триггер, то это перестанет быть нарушением?
   nicxxx
 
38 - 30.10.17 - 15:56
(29),(34) Ответственность не предусмотрена.
   Alex_MA
 
39 - 30.10.17 - 16:11
(0)нет покрывающего индекса.
Т.е. ты выбираешь поля из документа (но отбор по дате), которых нет в составе индекса по дате.

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

Затем выбирать запросом из этого регистра.
Вариант_2: Добавить в индекс по дате - все необходимые поля выборки в MS SQL Server. В этом есть минус - следующее обновление конфигурации твой индекс уберет.
   vde69
 
40 - 30.10.17 - 16:21
(29) (26) читаем

Гражданский кодекс РФ от 18.12.2006 N 230-ФЗ - Часть 4 Статья 1280. Свободное воспроизведение программ для ЭВМ и баз данных.
   arsik
 
41 - 30.10.17 - 16:22
(29) "которые вносятся штатными средствами, входящими в состав ПРОГРАММНОГО ПРОДУКТА и описанными в сопроводительной документации;"
Так то MS SQL server + SSMS - входят в состав программного продукта. Вы еще softpoint пож это подведите.
   Alex_MA
 
42 - 30.10.17 - 16:22
(0)Решение проблемы в данном случае сводится к тому, чтобы создать хранение данных наподобие аля-кластерный индекс "по дате"
   rphosts
 
43 - 30.10.17 - 16:40
(40) (41) спросите это у представителей 1С - узнаете много нового.
   rphosts
 
44 - 30.10.17 - 16:41
(41) >Так то MS SQL server + SSMS

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

про софтпоинт опять-же уточняйте в фирме 1С - у них может быть спецсоглашение
   Tateossian
 
45 - 30.10.17 - 16:43
(29) Тогда на ИТС зачем мануалы написаны
   Tateossian
 
46 - 30.10.17 - 16:43
   arsik
 
47 - 30.10.17 - 16:52
(45) Кстати да. (43) короче твое айяйяй только у тебя в голове.
   ptiz
 
48 - 30.10.17 - 16:52
(39) Я оставил самый минимум: номер и дату. Сделал покрывающий индекс (через "помощника настройки ядра СУБД" - подсунул ему этот запрос). Один черт - индекс скан по этому индексу, скорость такая же.
https://yadi.sk/i/T-kBh5s73PENoR
   ptiz
 
49 - 30.10.17 - 16:53
Видимо, sql не может переварить запрос с такой кучей условий на даты, который генерит список документов.
 
  Рекламное место пустует
   vde69
 
50 - 30.10.17 - 16:53
(48) так оптимизатор заработает по новому индексу только после сброса статистики
   rphosts
 
51 - 30.10.17 - 16:56
(46) не приятгивайте за уши методологию обслуживания БД с вмешательством в структуру Б
   rphosts
 
52 - 30.10.17 - 16:56
Б= ИБ
   rphosts
 
53 - 30.10.17 - 16:58
(48) 1802 это Duration?
   rphosts
 
54 - 30.10.17 - 16:59
(50) и чистки процедурного кэша... и да, дефрагментацию давно выполняли?
   alkorolev
 
55 - 30.10.17 - 17:06
(45) мануалы написаны по сопровождению СУБД, а не об изменении физической сущности базы НЕ средствами эсочки. Грубо говоря, если вы покупаете УТ, вставляете триггер, где при инсёрте нового элемента номенклатуры реиндексируете всю базу, а потом жалуетесь в компанию 1С, что их программа тормозит и г*вно, то 1С в свою очередь может вас послать (и обязательно пошлёт).
   Alex_MA
 
56 - 30.10.17 - 17:12
(48)Видимо из статистических данных MSSQL решил что так будет оптимальнее...(На выполнение запроса может повлиять и статистика)
   alkorolev
 
57 - 30.10.17 - 17:13
(0) рлс исключил? под полными правами тож торомзит? создай обработку, сделай в ней форму списка журнала документов. Что за привычка сразу в профайлер лезть?
   breezee
 
58 - 30.10.17 - 17:15
(17) Попробуйте перевести этот список на управляемые. Планы обслуживания на скуле смотрели?
   alkorolev
 
59 - 30.10.17 - 17:15
SELECT TOP 51
   alkorolev
 
60 - 30.10.17 - 17:15
это динамический запрос что ль? что вообще за программа?
   rphosts
 
61 - 30.10.17 - 17:17
(57) в профайлере запрос с учетом рлс, тебе ли этого не знать
   rphosts
 
62 - 30.10.17 - 17:17
(60) видимо запрос динамического списка
   Ёпрст
 
63 - 30.10.17 - 17:18
а в результате окажется, что на форме есть какой либо текстовый реквизит, который получает значение из текущей строки списка, таща на клиента весь объект целиком
   vde69
 
64 - 30.10.17 - 17:21
(62) (63) как я понял у автора ОБЫЧНЫЕ формы
   vde69
 
65 - 30.10.17 - 17:22
(57) рельсы тут нет, это видно по запросу... рельса ВСЕГДА выполняется внутри ХП...
   craxx
 
66 - 30.10.17 - 17:23
(0)RLS?
   ptiz
 
67 - 30.10.17 - 17:34
(53) Да, он.
(63) Причем тут форма, если есть конкретный запрос SQL с duration 1800?
(66) С RLS запрос выглядел бы совсем по-другому.
   vde69
 
68 - 30.10.17 - 17:39
(67) кстати вопрос:

SQL на виртуалке?
   Ёпрст
 
69 - 30.10.17 - 17:39
(67) 1800- это же 1.8мс, долго ?
   rphosts
 
70 - 30.10.17 - 17:43
(69) Duration в миллисекундах, это 1,8 сек
   Ёпрст
 
71 - 30.10.17 - 17:44
(70) разве ? А не в микросекундах ?
   Ёпрст
 
72 - 30.10.17 - 17:44
не помню ужо
   ptiz
 
73 - 30.10.17 - 17:44
(68) Нет конечно.
   rphosts
 
74 - 30.10.17 - 17:44
(67) можно текстовый план запроса?
   mistеr
 
75 - 30.10.17 - 17:49
Не вижу плана почему-то (что-то с Яндексом). Так что там с индексом, поясните кто вкурил? Индекс по дате+ссылке должен быть стандартный у всех доков, предназначен именно для списков. Чтобы при запросе дин. списка скуль пошел не по этому индексу, это нужно очень постараться.

Может сортировка в списке не та? Может нужно сделать ТИИ с реиндексацией?
   vde69
 
76 - 30.10.17 - 17:50
в свойствах базы смотри все параметры типа

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

зы
мне кажется, что дело именно в статистике
   rphosts
 
77 - 30.10.17 - 17:54
(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
   ptiz
 
78 - 03.11.17 - 15:27
(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 - и всё. И это медленно.
   rphosts
 
79 - 03.11.17 - 17:26
(78) время адекватное запросу... сделайте новый журнал без единой строчки кода, откройте под пользователем с полными правами
   mistеr
 
80 - 03.11.17 - 18:03
(78) Clustered Index Scan и должен быть. План нормальный. Странно, что медленно. статистику по I/O бы глянуть...

Может все-таки переиндексировать? Кто в курсе, при ТИИ кластерные индексы пересоздаются?
   ptiz
 
81 - 03.11.17 - 19:42
(80) Переиндексировал, и через 1С реструктуризировал журнал (когда графы меняешь).
Я бы согласился, что нормально, но когда снизу вверх листаешь - всё намного быстрее :(
   ptiz
 
82 - 03.11.17 - 19:43
(79) А какая графа тут время отображает? И в каких единицах?
   mistеr
 
83 - 03.11.17 - 19:46
(81) Со стороны 1С все норм, проблема в скуле имхо. Или в конкретной базе.
   mistеr
 
84 - 03.11.17 - 19:47
(81) Раз уж тронул журнал, попробуй из состава доки убрать, чтоб он очистился. А потом вернуть.
   Borteg
 
85 - 03.11.17 - 22:20
(0) в обеих списках в запросе нету поля description, при выводе на каждую строку идут обращения к sql?
   Borteg
 
86 - 03.11.17 - 22:22
(78) при --Top(TOP EXPRESSION:((47)))  всегда будет скан это самое быстро что можно сделать
   Borteg
 
87 - 03.11.17 - 22:46
(0) скорей всего проблема в ссылочных типах и их выводе на экран. надо выводить представление от ссылки, а ссылки скрывать видимость(если нужны отборы)
   Cyberhawk
 
88 - 03.11.17 - 23:17
Думаю, после праздников проблема сама собою рассосется
   youalex
 
89 - 03.11.17 - 23:18
(78) какое-то дикое условие
попробовал на своем журнале (отбор по периоду установлен, видимость ссылочных колонок отключена):

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

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

Пробуй, как уже сказали, ЖурналСписок в новой, пустой форме. Интересно, дин. список какой запрос сформирует.
На крайний, журнал всегда можно заэмулировать через РС.
   Sasha_H
 
90 - 03.11.17 - 23:23
   Sasha_H
 
91 - 03.11.17 - 23:25
(0)
Полагаю, что у автора все регламенты, статистика/индексы обновляются.

Попробую в настройках списка вообще установить полные стандартные настройки. Вообще снять сортировку любого рода.
   Sasha_H
 
92 - 03.11.17 - 23:26
очень помагает еще использование последней платформы
   Sasha_H
 
93 - 03.11.17 - 23:28
советую использовать 8.3
   mistеr
 
94 - 03.11.17 - 23:29
(89) Там не один запрос идет, а несколько. Ты полистай туда-сюда.
   Sasha_H
 
95 - 03.11.17 - 23:34
Я может где-то пропустил это же УФ или обычная форма?
   youalex
 
96 - 03.11.17 - 23:35
(94) Ну да. Параметры меняются.
   mistеr
 
97 - 03.11.17 - 23:36
(90) >проблемы в операторе ORDER BY,  который платформа сама старательно добавляет, и неважно, что сортировка вообще пользователем не указана
>Осталось только ждать и надеяться, что 1С все-таки согласится исправить такое поведение ДС

Вывод автор статьи сделал неверный. Без ORDER BY не будет никакого ДС. Важно, чтобы этот ORDER BY попадал в индекс и не требовал доп. сортировки. В остальном статья норм.
   mistеr
 
98 - 03.11.17 - 23:38
(96) Не только параметры, но и сами запросы. Просто задумайся над условием "_Date_Time = @P3"
   Sasha_H
 
99 - 03.11.17 - 23:38
(97) спорно. и можем много спорить. Ест-но что без сортировки не будет ДС. Но как ведомо сортировка отжирает весомый процент.
   Sasha_H
 
100 - 03.11.17 - 23:40
(97) ну вот и тебе ответ обрати внимание на покрытия своих индексов, на что идет трудоемкость в плане запроса. Поиск ключа.

  1  2   

Список тем форума
  Рекламное место пустует
Пользователь не знает, чего он хочет, пока не увидит то, что он получил.
Э. Йодан
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует