Простейший запрос:

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

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   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]))

(0) ты посмотри, во что (1,2) в (Выбрать 1,2 из ВТ) превращается...

там трэш

(1) Какая разница?

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

(1) хех, надо на 18 релизе глянуть. они же написали что наоптимизировали чего то там.

какая разница, какой релиз.
Речь про SQL

(4) ты чуешь коррелированный запрос

(7) Я даже слова такого не знаю.

кластеред индекс скан = тэйбл скан

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

(9) Счегобы?

(10) в данном случае это быстрее

индекс содержит все измерения

(13) Нет

(11) ведь скан, а не сиик

Именно это и удивляет.

(15) Скан индекса, а не таблицы.

(14) как это не содержит, врешь

(4) Да, прикольно... Может, оптимизатор запросов БД не обращает внимания на выбираемые поля?

(18) Период, Регистратор, НомерСтроки

Да не поэтому, а потому что он КЛАСТЕРНЫЙ - это и есть физ. записи в таблицах

А порядок измерений в регистре какой? И какие измерения индексированы дополнительно?

(20) это для обхода коррелированного запроса, но сугубо имхо

(21) +1

(21) Нет

(21) не

(21) В кластерном данные - сразу, но только тех полей, которые в нем.

http://msdn.microsoft.com/ru-ru/library/ms187638(v=sql.105).aspx

Это копия, а не ссылка.

(28) Вложенные в терминологии 1С?

(28) там exist используется

(27) это в обычном индексе

(31) да, но он все равно вызывается для каждой строки внешнего запроса (т.е. таб. регистра)

Кластерный индекс, это не индекс, а физ порядок

(27) Кластерный индекс вроде все поля содержит же. Те, по поля по которым строится - порядок определяют.

Четовы меня смутили. Пойду почитаю про кластерный

(33) в случае с Exist работает быстрее чем внутреннее соединение

(37) эксистс - это тупо приближенно "селект топ 1"

ведь что есть внутреннее соединение - nested lookup, и вложенный тоже самое

(38) не сомвем

(36) Тю. Я думал, вопрос был в том, почему не используется подходящий индекс, вместо скана таблицы.

(37) пусть автор ответит, быстрее, или нет :)

на 2000 во времена 77 точно быстрее было. сам проверял

Все, извиняюсь, кластерный индекс содержит данные.

Но план запроса все равно это не объясняет.

(45) и что не понятно с учетом (9)

Тааааак

sql построил хэш по 2-м полям и давай сканировать таблицу, но сканировать упорядоченно по кластерному индексу, так?

момент

вообще, конечно, не хватает возможности лепить свои составные индексы

Я не могу добиться TableScan-а

Чтобы понять

Как только в таблице имеется кластерный индекс, IAM более не используется для доступа к данным. IAM не исчезает вообще, но используется только для сопровождения таблицы как объекта в базе данных. Страницы данных взаимосвязаны и данные в них находятся в соответствии с кластерным индексом.

Если выполнить запрос SELECT * FROM Customers без каких-либо условий WHERE, то система выполнить сканирование таблицы с использованием кластерного индекса. Эта операция очень похожа на простое сканирование таблицы. Главное различие между сканированием по кластерному индексу то, что результат сканирования вернется в порядке сортировки по кластерному индексу.

Все, понял, разобрался.
Ascent-у респект и уважуха.

(54)  а (42)?

(55) Я на Exist забил.

(50) Тады точно SAP и другие помрут ))))

Вернемся к нашим песням.

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

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

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

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

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

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

Что думаете?

Ладно, другой вопрос - почему в Типовых Серия не индексированна?

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

а по алгоиртмам выбирается номенклатура + серия

(61) Ну и что.

(61) Вообще странно все.

Выбираю по серии и номенклатуре.

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

Почему в 1 случае SQL делает Index Scan, ведь у него индекс есть по номенклатуре!

Счаст попробую Первый случай, но отбирать буду только по номенклатуре, а в выборку включу Серию, Index Scan он мне сделает, или Index Seek по номенклатуре...

(64)
1. оптимизатор решил, что использовать индекс по номенклатуре неоптимально, попробуй статистику обновить
2 и 3 - одинаково по сути, так как правильных составных индексов нету. но никто не мешает навешивать свои составные индексы (до реструктуризиции, правда)

(67) Индексированна Серия.
И ищем по Серии и Номенклатуре.

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

?

Пардон, спешу добавить....
И мы не просто ищем серию  и номенклатуру, но мы еще и Количество их берем :-)

а оптимизатор об этом знает? какой % записей с пустой?

вообще - индексирована серия - значит составной индекс на серию, период, регистратор, номер строки.... - оптимизатор думает, что ну его нафиг, погляжу ка я всю таблицу...

(71) Я не про то.

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

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


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

SQL найдет по индексу "ПустаяСерия" идентификатор строки и слазит в таблицу проверить Жигулиэто или нет.  А это не Жигули, а Камаз. Неудача. Тут бы составной индекс и пригодился.

(72) ms sql 2008 r2 пока так не думает.

(73) Просто таких пустых серий У МЕНЯ будет мало.

А вот типовые конфы универсальны, учет может быть и без серий, поэтому Серия и не индексированна.

(75) Или нет?

(66) Clastered Index Scan, блин.

Серию убираю, только номенклатура в Выборке - Index Seek без Lookup-а, но это то понятно.

сделай свой индекс ТОЛЬКО по серии, будет отбирать по нему

(79) Это и работает.

(79) Для Серии - работает.
Для Номенклатуры - нет.

Статистику - обновлял.

Выбираю по серии и номенклатуре.

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


1 случай, отбирать буду только по номенклатуре, а в выборку включаю Серию. Хочу IndexSeek + Lookup, получаю Clastered Index Scan (Table Scan) по факту.

(80) т.е. не галочки в 1с, а именно руками созданные индексы?

(83) Нет, галочки.

(83) Предлагаешь создать отдельный некластерный индекс только по полю Номенклатура, в SQL ?

(85) галочки в 1с не рулят

рестартани скуль, если есть возможность, и:

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;

ну и отбор по имени таблицы

это после пары десятков своих запросов

(87) Нет возможности пока. Будет ближе к ночи.

СОздал чистый индекс по номенклатуре, не использует его никак, использует старый индекс с Регистратором и Периодом, и.т.д. Статистику обновил, что еще надо сделать?

Ооо, снесу старый :-)

Ооо, стал использовать Мой Индекс, когда в выборке тока номенклатура.

И Clastered Index Scan, когда в выборке добавляю еще и Серию, пичаль.

Ладно, пойду поем, а ночью, когда никто не видит, буду ставить опыты.

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

Фсе, отбой.
Дело было в селективности.

Номенклатура была часто встречающаяся в регистре - и поэтому выбирался Index Scan, а потом уж отбор по серии - и в выборке у меня было мало записей, а когда отключил отбор по серии и тупо ее в выборке выводил - уже не обратил внимания на то, что там дофига записей.

Фсе, домой! Пишите, если что.

(0)
в данном примере лучше заменить на такой вариант

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

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

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

(100) Для клиент-серверного варианта
ИНДЕКСИРОВАТЬ ПО СерияНоменклатуры;
может замедлить скорость выполнения

(10) +1
ВТ внутреннее Товары

Пятничный разрыв мозга:

Расчет итогов, зависает вплоть до бесконечности:
Этот запрос, на котором останавливается (расчет итогов по счетам, у которых 5 субконто)
http://pastebin.com/7SAGwHPP
расчет по 4 субконто выполнился за 40 минут, этот, соответственно, выполнится вооще непонятно за сколько.
План счетов страшен, счетов с 5 субконто дофига. Что можно сделать?
Раньше помогала реструктуризация и расчет итогов сразу после нее, сейчас уже не взлетает. Есть предложения, как все таки это сделать за приемлемое время?

(103) считать итоги кусками

(104) не понял? оно и так кусками - порегистрово помесячно

(103)
заведите отдельную ветку

а по вопросу - перепишите на более отимальные

(106) это РегистрБухгалтерии.Регистр.УстановитьПериодРассчитанныхИтогов

(107)
какая разница.

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

иногда никакое железо их неотимальность неисправит.

(105) (107)
РегистрБухгалтерии.Регистр.УстановитьПериодРассчитанныхИтогов
1. сначала дата ('00010101') (очистил все итоги)
2. выключит текущие итоги
далее погнал
УстановитьПериодРассчитанныхИтогов('20130101')
УстановитьПериодРассчитанныхИтогов('20130201')
УстановитьПериодРассчитанныхИтогов('20130301')

(107) Это МихаилМ, человек, в 98% случаев не давший конкретного ответа, настоящий программист.

(109) так и есть. Идет по 3-5 минут месяц, в определенный момент зависает. срубаешь все, откатываешь - и уже вообще не считается, либо зависает намного раньше.

(105)Иногда помогало персчитать статистику скулем по регистрам бухгалтерии непосредственно перед расчетом.
+ избавляться от 5 субконто :)

Бррр, хорошо, что у меня такой херни нет.

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

Посмотрел текст запроса. Доходу, разработчики движка не знали про временные таблицы, когда писали этот код, скорее всего древний, как сама 8.0

(115) дело в большом количестве соединений. ну и да - про временные таблицы они знали, ибо там ВТ со счетами и количеством субконто на них есть

лично я бы сделал соединение и сворачивание

*объединение

или соединение и ВЫБОР когда номерстроки = ... тогда...

одно соединение

(109) всегда спотыкается в одном периоде?

(109) что делает sql в момент зависания?

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

сейчас попробовал (112) не взлетело, опять остановилось на 4 субконто, подозреваю, что через пол часика перейдет на 5 субконто и все...

ровно через пол часа начало считать пятое субконто

(124) платформа полностью завершала расчет или всегда "подвисала"?

(123) никак без 5 субконто? у ПВХ хоть все значения ссылочные?

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

(126) да, там только ссылки. от 5 субконто по воле бухов не избавится

интересно, что сейчас оно не считается даже по тем данным, по которым раньше считалось нормально

с 5 субконто 17 счетов

всего 114

(127) теперь не прокатывает?
Какое количество записей в таблицах, как обстоят дела с итогам на каждый месяц, идет -ли закрытие счетов, какой релиз платформы, сообщал эту информацию в 1с (или на партнерке), делал-ли проверку логической целостности.

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

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