Имя: Пароль:
1C
1С v8
v8: Опять использование индексов
0 H A D G E H O G s
 
10.04.13
18:03
Простейший запрос:

ВЫБРАТЬ
   РеализацияТоваровУслугТовары.Ссылка.Организация,
   РеализацияТоваровУслугТовары.СерияНоменклатуры
ПОМЕСТИТЬ ВТ
ИЗ
   Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ
   РеализацияТоваровУслугТовары.Ссылка = &Ссылка
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   1 КАК Поле1
ИЗ
   РегистрНакопления.ТоварыОрганизаций КАК ТоварыОрганизаций
ГДЕ
   (ТоварыОрганизаций.Организация, ТоварыОрганизаций.СерияНоменклатуры) В
           (ВЫБРАТЬ
               СерииДокумента.Организация,
               СерииДокумента.СерияНоменклатуры
           ИЗ
               ВТ КАК СерииДокумента)


2 запрос дает Clustered Index Scan по индексу: _Accum20481_ByPeriod_TRN, хотя в него не входит ни СерияНоменклатуры ни Организация из регистра накопления. Как так?!

Вот план запроса:

StmtText    
Hash Match(Right Semi Join, HASH:([T2].[_Q_000_F_000RRef], [T2].[_Q_000_F_001RRef])=([T1].[_Fld20482RRef], [T1].[_Fld20486RRef]), RESIDUAL:([Database].[dbo].[_AccumRg20481].[_Fld20482RRef] as [T1].[_Fld20482RRef]=[tempdb].[dbo].[#tt2].[_Q_000_F_000RRef] as [T2].[_Q_000_F_000RRef] AND [Database].[dbo].[_AccumRg20481].[_Fld20486RRef] as [T1].[_Fld20486RRef]=[tempdb].[dbo].[#tt2].[_Q_000_F_001RRef] as [T2].[_Q_000_F_001RRef]))
 |--Table Scan(OBJECT:([tempdb].[dbo].[#tt2] AS [T2]))

|--Clustered Index Scan(OBJECT:([Database].[dbo].[_AccumRg20481].[_Accum20481_ByPeriod_TRN] AS [T1]))
1 Fragster
 
гуру
10.04.13
18:06
(0) ты посмотри, во что (1,2) в (Выбрать 1,2 из ВТ) превращается...
2 Fragster
 
гуру
10.04.13
18:06
там трэш
3 H A D G E H O G s
 
10.04.13
18:07
(1) Какая разница?
4 H A D G E H O G s
 
10.04.13
18:08
exec sp_executesql N'SELECT
P1
FROM _AccumRg20481 T1 WITH(NOLOCK)
WHERE EXISTS(SELECT
1
FROM #tt2 T2 WITH(NOLOCK)
WHERE (T1._Fld20482RRef = T2._Q_000_F_000RRef) AND (T1._Fld20486RRef = T2._Q_000_F_001RRef))',N'P1 numeric(1)',1
5 rs_trade
 
10.04.13
18:08
(1) хех, надо на 18 релизе глянуть. они же написали что наоптимизировали чего то там.
6 H A D G E H O G s
 
10.04.13
18:09
какая разница, какой релиз.
Речь про SQL
7 Fragster
 
гуру
10.04.13
18:09
(4) ты чуешь коррелированный запрос
8 H A D G E H O G s
 
10.04.13
18:10
(7) Я даже слова такого не знаю.
9 acsent
 
10.04.13
18:10
кластеред индекс скан = тэйбл скан
10 Fragster
 
гуру
10.04.13
18:10
короче, замени на внутреннее соединение
11 H A D G E H O G s
 
10.04.13
18:11
(9) Счегобы?
12 acsent
 
10.04.13
18:11
(10) в данном случае это быстрее
13 acsent
 
10.04.13
18:11
индекс содержит все измерения
14 H A D G E H O G s
 
10.04.13
18:11
(13) Нет
15 acsent
 
10.04.13
18:11
(11) ведь скан, а не сиик
16 H A D G E H O G s
 
10.04.13
18:11
Именно это и удивляет.
17 H A D G E H O G s
 
10.04.13
18:12
(15) Скан индекса, а не таблицы.
18 acsent
 
10.04.13
18:12
(14) как это не содержит, врешь
19 fisher
 
10.04.13
18:12
(4) Да, прикольно... Может, оптимизатор запросов БД не обращает внимания на выбираемые поля?
20 H A D G E H O G s
 
10.04.13
18:12
(18) Период, Регистратор, НомерСтроки
21 acsent
 
10.04.13
18:13
Да не поэтому, а потому что он КЛАСТЕРНЫЙ - это и есть физ. записи в таблицах
22 fisher
 
10.04.13
18:13
А порядок измерений в регистре какой? И какие измерения индексированы дополнительно?
23 Fragster
 
гуру
10.04.13
18:14
(20) это для обхода коррелированного запроса, но сугубо имхо
24 fisher
 
10.04.13
18:14
(21) +1
25 H A D G E H O G s
 
10.04.13
18:14
(21) Нет
26 Fragster
 
гуру
10.04.13
18:14
(21) не
27 H A D G E H O G s
 
10.04.13
18:14
(21) В кластерном данные - сразу, но только тех полей, которые в нем.
28 Fragster
 
гуру
10.04.13
18:15
29 H A D G E H O G s
 
10.04.13
18:15
Это копия, а не ссылка.
30 H A D G E H O G s
 
10.04.13
18:15
(28) Вложенные в терминологии 1С?
31 acsent
 
10.04.13
18:15
(28) там exist используется
32 acsent
 
10.04.13
18:16
(27) это в обычном индексе
33 Fragster
 
гуру
10.04.13
18:16
(31) да, но он все равно вызывается для каждой строки внешнего запроса (т.е. таб. регистра)
34 acsent
 
10.04.13
18:16
Кластерный индекс, это не индекс, а физ порядок
35 fisher
 
10.04.13
18:16
(27) Кластерный индекс вроде все поля содержит же. Те, по поля по которым строится - порядок определяют.
36 H A D G E H O G s
 
10.04.13
18:17
Четовы меня смутили. Пойду почитаю про кластерный
37 acsent
 
10.04.13
18:17
(33) в случае с Exist работает быстрее чем внутреннее соединение
38 Fragster
 
гуру
10.04.13
18:18
(37) эксистс - это тупо приближенно "селект топ 1"
39 acsent
 
10.04.13
18:18
ведь что есть внутреннее соединение - nested lookup, и вложенный тоже самое
40 acsent
 
10.04.13
18:18
(38) не сомвем
41 fisher
 
10.04.13
18:18
(36) Тю. Я думал, вопрос был в том, почему не используется подходящий индекс, вместо скана таблицы.
42 Fragster
 
гуру
10.04.13
18:19
(37) пусть автор ответит, быстрее, или нет :)
43 acsent
 
10.04.13
18:19
на 2000 во времена 77 точно быстрее было. сам проверял
44 H A D G E H O G s
 
10.04.13
18:28
Все, извиняюсь, кластерный индекс содержит данные.
45 H A D G E H O G s
 
10.04.13
18:29
Но план запроса все равно это не объясняет.
46 acsent
 
10.04.13
18:30
(45) и что не понятно с учетом (9)
47 H A D G E H O G s
 
10.04.13
18:30
Тааааак
48 H A D G E H O G s
 
10.04.13
18:31
sql построил хэш по 2-м полям и давай сканировать таблицу, но сканировать упорядоченно по кластерному индексу, так?
49 H A D G E H O G s
 
10.04.13
18:32
момент
50 Fragster
 
гуру
10.04.13
18:35
вообще, конечно, не хватает возможности лепить свои составные индексы
51 H A D G E H O G s
 
10.04.13
18:36
Я не могу добиться TableScan-а
52 H A D G E H O G s
 
10.04.13
18:36
Чтобы понять
53 H A D G E H O G s
 
10.04.13
18:39
Как только в таблице имеется кластерный индекс, IAM более не используется для доступа к данным. IAM не исчезает вообще, но используется только для сопровождения таблицы как объекта в базе данных. Страницы данных взаимосвязаны и данные в них находятся в соответствии с кластерным индексом.

Если выполнить запрос SELECT * FROM Customers без каких-либо условий WHERE, то система выполнить сканирование таблицы с использованием кластерного индекса. Эта операция очень похожа на простое сканирование таблицы. Главное различие между сканированием по кластерному индексу то, что результат сканирования вернется в порядке сортировки по кластерному индексу.
54 H A D G E H O G s
 
10.04.13
18:41
Все, понял, разобрался.
Ascent-у респект и уважуха.
55 Fragster
 
гуру
10.04.13
18:43
(54)  а (42)?
56 H A D G E H O G s
 
10.04.13
18:44
(55) Я на Exist забил.
57 Никола_
Питерский
 
10.04.13
20:20
(50) Тады точно SAP и другие помрут ))))
58 H A D G E H O G s
 
11.04.13
17:01
Вернемся к нашим песням.

Смотрим типовые - на всех регистрах стоит индексированное измерение "Номенклатура", но неиндексированное "Серия". Логично.

Но у меня есть регистр, который имеет измерение "Номенклатура" и "СерияНоменклатуры" (которое заполнено гораздо чаще чем в типовом случае).

На данный момент индексированна "Номенклатура", но почти во всех запросах к регистру в условиях есть Номенклатура и Серия.

Запросы скорее всего выполняют index seek nonclustered по индексу номенклатуры, а затем KeylookUp по физ. таблице по Серии.

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

И, как вариант - снять индекс с Номенклатуры и поставить на Серию.

Что думаете?
59 H A D G E H O G s
 
11.04.13
17:26
Ладно, другой вопрос - почему в Типовых Серия не индексированна?
60 Fragster
 
гуру
11.04.13
18:01
(59) потому что типовой механизм индексирования не дает делать нормально составные индексы
61 Fragster
 
гуру
11.04.13
18:02
а по алгоиртмам выбирается номенклатура + серия
62 H A D G E H O G s
 
11.04.13
18:03
(61) Ну и что.
63 H A D G E H O G s
 
11.04.13
18:03
(61) Вообще странно все.
64 H A D G E H O G s
 
11.04.13
18:05
Выбираю по серии и номенклатуре.

Индексированна номенклатура - Clastered Index Scan
Индексированна Серия - Index Seek+Lookup
Индексированна Серия и Номенклатура - Index Seek (по индексу Серии)+Lookup
65 H A D G E H O G s
 
11.04.13
18:06
Почему в 1 случае SQL делает Index Scan, ведь у него индекс есть по номенклатуре!
66 H A D G E H O G s
 
11.04.13
18:08
Счаст попробую Первый случай, но отбирать буду только по номенклатуре, а в выборку включу Серию, Index Scan он мне сделает, или Index Seek по номенклатуре...
67 Fragster
 
гуру
11.04.13
18:11
(64)
1. оптимизатор решил, что использовать индекс по номенклатуре неоптимально, попробуй статистику обновить
2 и 3 - одинаково по сути, так как правильных составных индексов нету. но никто не мешает навешивать свои составные индексы (до реструктуризиции, правда)
68 H A D G E H O G s
 
11.04.13
18:13
(67) Индексированна Серия.
И ищем по Серии и Номенклатуре.

Лишние lookup-ы будут только там, где серия пустая, зачем тут составной индекс (в индекс включать Номенклатуру).
69 H A D G E H O G s
 
11.04.13
18:14
?
70 H A D G E H O G s
 
11.04.13
18:15
Пардон, спешу добавить....
И мы не просто ищем серию  и номенклатуру, но мы еще и Количество их берем :-)
71 Fragster
 
гуру
11.04.13
18:16
а оптимизатор об этом знает? какой % записей с пустой?
72 Fragster
 
гуру
11.04.13
18:19
вообще - индексирована серия - значит составной индекс на серию, период, регистратор, номер строки.... - оптимизатор думает, что ну его нафиг, погляжу ка я всю таблицу...
73 H A D G E H O G s
 
11.04.13
18:21
(71) Я не про то.

Я про то, что
Вот ищем мы
Номенклатура       Серия
Лада               Калина

SQL найдет по индексу "Калина" идентификатор строки и слазит в таблицу проверить Лада это или нет. И заодно вытащит Количество. Все норм. Однозначно надо лезть в таблицу за количеством. Все норм.


Вот ищем мы
Номенклатура       Серия
Жигули             <ПустаяСерия>

SQL найдет по индексу "ПустаяСерия" идентификатор строки и слазит в таблицу проверить Жигулиэто или нет.  А это не Жигули, а Камаз. Неудача. Тут бы составной индекс и пригодился.
74 H A D G E H O G s
 
11.04.13
18:22
(72) ms sql 2008 r2 пока так не думает.
75 H A D G E H O G s
 
11.04.13
18:23
(73) Просто таких пустых серий У МЕНЯ будет мало.

А вот типовые конфы универсальны, учет может быть и без серий, поэтому Серия и не индексированна.
76 H A D G E H O G s
 
11.04.13
18:24
(75) Или нет?
77 H A D G E H O G s
 
11.04.13
18:27
(66) Clastered Index Scan, блин.
78 H A D G E H O G s
 
11.04.13
18:28
Серию убираю, только номенклатура в Выборке - Index Seek без Lookup-а, но это то понятно.
79 Fragster
 
гуру
11.04.13
18:29
сделай свой индекс ТОЛЬКО по серии, будет отбирать по нему
80 H A D G E H O G s
 
11.04.13
18:31
(79) Это и работает.
81 H A D G E H O G s
 
11.04.13
18:32
(79) Для Серии - работает.
Для Номенклатуры - нет.

Статистику - обновлял.
82 H A D G E H O G s
 
11.04.13
18:34
Выбираю по серии и номенклатуре.

1) Индексированна номенклатура - Clastered Index Scan
2) Индексированна Серия - Index Seek+Lookup
3) Индексированна Серия и Номенклатура - Index Seek (по индексу Серии)+Lookup


1 случай, отбирать буду только по номенклатуре, а в выборку включаю Серию. Хочу IndexSeek + Lookup, получаю Clastered Index Scan (Table Scan) по факту.
83 Fragster
 
гуру
11.04.13
18:34
(80) т.е. не галочки в 1с, а именно руками созданные индексы?
84 H A D G E H O G s
 
11.04.13
18:34
(83) Нет, галочки.
85 H A D G E H O G s
 
11.04.13
18:35
(83) Предлагаешь создать отдельный некластерный индекс только по полю Номенклатура, в SQL ?
86 Fragster
 
гуру
11.04.13
18:37
(85) галочки в 1с не рулят
87 Fragster
 
гуру
11.04.13
18:39
рестартани скуль, если есть возможность, и:

SELECT  TOP 10
       [Total Cost]  = ROUND(avg_total_user_cost * avg_user_impact * (user_seeks + user_scans),0)
       , avg_user_impact
       , TableName = statement
       , [EqualityUsage] = equality_columns
       , [InequalityUsage] = inequality_columns
       , [Include Cloumns] = included_columns
FROM        sys.dm_db_missing_index_groups g
INNER JOIN    sys.dm_db_missing_index_group_stats s
      ON s.group_handle = g.index_group_handle
INNER JOIN    sys.dm_db_missing_index_details d
      ON d.index_handle = g.index_handle
ORDER BY [Total Cost] DESC;
88 Fragster
 
гуру
11.04.13
18:40
ну и отбор по имени таблицы
89 Fragster
 
гуру
11.04.13
18:40
это после пары десятков своих запросов
90 H A D G E H O G s
 
11.04.13
18:40
(87) Нет возможности пока. Будет ближе к ночи.
91 H A D G E H O G s
 
11.04.13
18:42
СОздал чистый индекс по номенклатуре, не использует его никак, использует старый индекс с Регистратором и Периодом, и.т.д. Статистику обновил, что еще надо сделать?
92 H A D G E H O G s
 
11.04.13
18:42
Ооо, снесу старый :-)
93 H A D G E H O G s
 
11.04.13
18:43
Ооо, стал использовать Мой Индекс, когда в выборке тока номенклатура.
94 H A D G E H O G s
 
11.04.13
18:44
И Clastered Index Scan, когда в выборке добавляю еще и Серию, пичаль.
95 H A D G E H O G s
 
11.04.13
18:44
Ладно, пойду поем, а ночью, когда никто не видит, буду ставить опыты.
96 H A D G E H O G s
 
11.04.13
18:46
Я конечно догадываюсь, что дело в селективности, но вроде номенклатура достаточно уникальна, надо глянуть.
97 H A D G E H O G s
 
11.04.13
19:01
Фсе, отбой.
Дело было в селективности.
98 H A D G E H O G s
 
11.04.13
19:05
Номенклатура была часто встречающаяся в регистре - и поэтому выбирался Index Scan, а потом уж отбор по серии - и в выборке у меня было мало записей, а когда отключил отбор по серии и тупо ее в выборке выводил - уже не обратил внимания на то, что там дофига записей.
99 H A D G E H O G s
 
11.04.13
19:06
Фсе, домой! Пишите, если что.
100 Bober
 
11.04.13
19:11
(0)
в данном примере лучше заменить на такой вариант

ВЫБРАТЬ
   РеализацияТоваровУслугТовары.СерияНоменклатуры КАК СерияНоменклатуры
ПОМЕСТИТЬ ВТ
ИЗ
   Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ
   РеализацияТоваровУслугТовары.Ссылка = &Ссылка
ИНДЕКСИРОВАТЬ ПО СерияНоменклатуры;

////////////////////////////////////////////////////////////////////////////////

ВЫБРАТЬ
   1 КАК Поле1
ИЗ
   РегистрНакопления.ТоварыОрганизаций КАК ТоварыОрганизаций
ГДЕ
   ТоварыОрганизаций.Организация = &Организация И ТоварыОрганизаций.СерияНоменклатуры В
           (ВЫБРАТЬ
               СерииДокумента.СерияНоменклатуры
           ИЗ
               ВТ КАК СерииДокумента ГДЕ  ТоварыОрганизаций.СерияНоменклатуры = СерииДокумента.СерияНоменклатуры)
101 masenshi
 
12.04.13
04:08
(100) Для клиент-серверного варианта
ИНДЕКСИРОВАТЬ ПО СерияНоменклатуры;
может замедлить скорость выполнения
102 masenshi
 
12.04.13
04:11
(10) +1
ВТ внутреннее Товары
103 Fragster
 
гуру
12.04.13
18:14
Пятничный разрыв мозга:

Расчет итогов, зависает вплоть до бесконечности:
Этот запрос, на котором останавливается (расчет итогов по счетам, у которых 5 субконто)
http://pastebin.com/7SAGwHPP
расчет по 4 субконто выполнился за 40 минут, этот, соответственно, выполнится вооще непонятно за сколько.
План счетов страшен, счетов с 5 субконто дофига. Что можно сделать?
Раньше помогала реструктуризация и расчет итогов сразу после нее, сейчас уже не взлетает. Есть предложения, как все таки это сделать за приемлемое время?
104 Bober
 
12.04.13
18:21
(103) считать итоги кусками
105 Fragster
 
гуру
12.04.13
18:26
(104) не понял? оно и так кусками - порегистрово помесячно
106 МихаилМ
 
12.04.13
18:27
(103)
заведите отдельную ветку

а по вопросу - перепишите на более отимальные
107 Fragster
 
гуру
12.04.13
18:29
(106) это РегистрБухгалтерии.Регистр.УстановитьПериодРассчитанныхИтогов
108 МихаилМ
 
12.04.13
18:32
(107)
какая разница.

1с часто неотимальнуе запросы генерирует.

иногда никакое железо их неотимальность неисправит.
109 Bober
 
12.04.13
18:33
(105) (107)
РегистрБухгалтерии.Регистр.УстановитьПериодРассчитанныхИтогов
1. сначала дата ('00010101') (очистил все итоги)
2. выключит текущие итоги
далее погнал
УстановитьПериодРассчитанныхИтогов('20130101')
УстановитьПериодРассчитанныхИтогов('20130201')
УстановитьПериодРассчитанныхИтогов('20130301')
110 H A D G E H O G s
 
12.04.13
18:33
(107) Это МихаилМ, человек, в 98% случаев не давший конкретного ответа, настоящий программист.
111 Fragster
 
гуру
12.04.13
18:34
(109) так и есть. Идет по 3-5 минут месяц, в определенный момент зависает. срубаешь все, откатываешь - и уже вообще не считается, либо зависает намного раньше.
112 Sammo
 
12.04.13
18:35
(105)Иногда помогало персчитать статистику скулем по регистрам бухгалтерии непосредственно перед расчетом.
+ избавляться от 5 субконто :)
113 H A D G E H O G s
 
12.04.13
18:37
Бррр, хорошо, что у меня такой херни нет.
114 H A D G E H O G s
 
12.04.13
18:39
А я в своем регистре вообще индексы выключил, раньше был по Номенклатуре, и как оказалось, он не пользуется. А по серии нужен только при печати печатной формы, и то в редких случаях, не факт что ей пользуются, а если пользуются - не жалуются на быстродействие. Нуегона, заводить спец. для них.
115 H A D G E H O G s
 
12.04.13
18:40
Посмотрел текст запроса. Доходу, разработчики движка не знали про временные таблицы, когда писали этот код, скорее всего древний, как сама 8.0
116 Fragster
 
гуру
12.04.13
18:42
(115) дело в большом количестве соединений. ну и да - про временные таблицы они знали, ибо там ВТ со счетами и количеством субконто на них есть
117 Fragster
 
гуру
12.04.13
18:43
лично я бы сделал соединение и сворачивание
118 Fragster
 
гуру
12.04.13
18:44
*объединение
119 Fragster
 
гуру
12.04.13
18:45
или соединение и ВЫБОР когда номерстроки = ... тогда...
120 Fragster
 
гуру
12.04.13
18:45
одно соединение
121 Bober
 
12.04.13
18:53
(109) всегда спотыкается в одном периоде?
122 Bober
 
12.04.13
18:55
(109) что делает sql в момент зависания?
123 Fragster
 
гуру
12.04.13
19:03
(121) после того, как споткнется - уже и на более ранних начинает останавливаться
(122) кушает проц, диски чуть-чуть периодами

сейчас попробовал (112) не взлетело, опять остановилось на 4 субконто, подозреваю, что через пол часика перейдет на 5 субконто и все...
124 Fragster
 
гуру
12.04.13
19:31
ровно через пол часа начало считать пятое субконто
125 Bober
 
12.04.13
19:56
(124) платформа полностью завершала расчет или всегда "подвисала"?
126 Bober
 
12.04.13
19:57
(123) никак без 5 субконто? у ПВХ хоть все значения ссылочные?
127 Fragster
 
гуру
12.04.13
20:02
(125) я же говорю - раньше после реструктуризации прокатывало, сейчас же не хочет уже. в предыдущие разы (как и в этот, собственно) сравнивал содержимое скулевых таблиц - оно совпадало до реструктуризации и после
128 Fragster
 
гуру
12.04.13
20:03
(126) да, там только ссылки. от 5 субконто по воле бухов не избавится
129 Fragster
 
гуру
12.04.13
20:05
интересно, что сейчас оно не считается даже по тем данным, по которым раньше считалось нормально
130 Fragster
 
гуру
12.04.13
20:05
с 5 субконто 17 счетов
131 Fragster
 
гуру
12.04.13
20:06
всего 114
132 Bober
 
13.04.13
12:40
(127) теперь не прокатывает?
Какое количество записей в таблицах, как обстоят дела с итогам на каждый месяц, идет -ли закрытие счетов, какой релиз платформы, сообщал эту информацию в 1с (или на партнерке), делал-ли проверку логической целостности.

У инталева вроде еще больше субконто и ничего, люди работаю.

Ps включено разделение итогов? Я бы взял базу, вырезал все из нее, кроме аналитики субконто, один документ, пвх план счет и этот регистр. Все движения навесил на этот документ и проверил -бы расчет итогов.
Ошибка? Это не ошибка, это системная функция.