Для чего нужно индексирование временных таблиц 1с
Доброго дня, коллеги! Если вы на практике не сталкивались с временными таблицами, в которых более 1000 записей, и с необходимостью их индексирования, то будем считать, что вам “повезло” и вопросы оптимизации и производительности вам чужды :) Успешно с этим жить и спокойно работать можно и дальше, но ровно до того момента, как вы решите сдать экзамен по платформе. В этом случае хотя бы в теории нужно изучить условия индексирования временных таблиц!
Вопрос
Разработчики 1С рекомендуют индексировать временные таблицы при 1000+ записей. На моей практике ни разу не встречал ситуаций, когда временная таблица содержит такое количество строк, тем более, такое количество строк в документах. У Вас же в примерах индексируется большая часть временных таблиц. На экзамене обязательно индексировать временные таблицы в запросе?
Ответ
Для индексирования временных таблиц есть формальные признаки – использование этих таблиц в отборах и соединениях. А есть более тонкие соображения – насколько оправданно будет индексировать эти таблицы, учитывая потенциальные затраты на эти операции и возможный выигрыш от использования индексов. Данный экзамен – на знание основных механизмов платформы, знание упомянутых “тонкостей” и нюансов оптимизации здесь не является обязательным, это уже уровень “1С:Эксперт”. Для данного экзамена использовался упрощенный подход – по формальным признакам. Ведь заранее не известен размер таблиц. Если экзаменатор увидит в запросе временную таблицу, где нет индексов, но по формальным признакам они нужны, будет непонятно: либо автор не знает про индексацию, либо эти индексы не используются намеренно, по каким-то соображениям. В данном курсе для упрощения, везде, где временные таблицы используются в отборах или соединениях, индексы включали – чтобы не возникало претензий с формулировкой “В задачах получения данных из информационной базы установка отборов по неиндексированным полям”. Если же Вы решите намеренно не использовать индексы исходя из приведенных Вами соображений, лучше привести эти аргументы в пояснении к решению, чтобы у экзаменатора не было сомнений не сей счет.
Использование индексов 1С — важнейший момент в оптимизации работы информационной системы 1С. Но они очень часто игнорируются разработчиками.
Ниже я попытаюсь рассказать, что же это такое — индексы 1С 8.3, и как их использовать.
Что же такое индексы в 1С?
Индексы представляют собой структуру, позволяющую выполнять ускоренный доступ к строкам таблицы на основе значений одного или более ее столбцов. Индексы сокращают объем данных, которые необходимо считать, чтобы возвратить результирующий набор.
В 1С индексом таблицы является совокупность реквизитов с установленным флагом «индексировать». Но у каждой таблицы есть свои особенности. Например, в индекс у регистра бухгалтерии автоматически попадают поля период и счет. Их рекомендуют использовать для оптимизации работы системы.
Индекс хранится в отдельной таблице БД, где связывает определенные строки таблицы с ключами индексов. Т.е. при поиске не нужно обходить все строки базы данных, а последовательно по ключам отбирать наборы записей и перебирать уже небольшие наборы информации.
Из-за особенностей СУБД каждая из них накладывает свои ограничения на использования индексов:
Ограничения на индексы в файловой базе 1С
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
В файловой базе единственным ограничением является максимальная длина ключа индекса, которая ограничивается 1920 байтами. При попытке реструктуризации базы данных с ключом большей длины появится ошибка — «Длина ключа индекса превышает максимально допустимую«.
Ограничения на индексы в базе 1С на MS SQL
На MS SQL, согласно документации, к ограничениям по длине индекса добавляется еще и количество ключей индекса, если количество полей будет превышено, индекс просто обрежется:
- количество ключей индекса — максимум 16
- суммарная длина индекса — 900 байт
Рекомендации по оптимизации работы 1С
- не рекомендуется использовать большое количество измерений и субконто в регистрах бухгалтерии;
- в планах счетов в рекомендациях устанавливать не более 4 субконто;
- нежелательно использовать поля составного типа — это сильно понижает скорость работы системы;
- не рекомендуется в измерениях регистров использовать поля с примитивным типом (число, строка и т.п.), если необходимо использовать значения примитивных видов, лучше создайте справочник, где будут указываться данные значения. Например: если Вы используете дату как измерение, лучше создать справочник «Даты», где единственным реквизитом будет реквизит с типом «дата»;
- не индексируйте строковые поля большой длины — это уменьшает быстродействие системы.
Разработчики 1С очень часто игнорируют использование конструкции «ИНДЕКСИРОВАТЬ ПО» в запросе.
Зачем нужно индексировать поля в запросе 1С 8.3, я расскажу ниже.
Как работает ИНДЕКСИРОВАТЬ ПО?
Индексация в запросе нужна для более быстрого формирования результате запроса. Как это работает? Система строит индекс для временной таблицы, чтобы быстрее найти нужное значение.
Т.е. система работает точно так же, как и обычные индексы 1С, только для временной таблицы.
Где и как нужно использовать ИНДЕКСИРОВАТЬ ПО ?
Конструкцию рекомендуется использовать по полям временных таблиц, по которым эта временная таблица будет соединяться с другими таблицами баз данных. Это существенно повышает скорость выполнения соединения таблиц.
Однако следует учесть один момент. Построение индекса временной таблицы также требует времени на выполнение. Поэтому целесообразно использовать конструкцию «ИНДЕКСИРОВАТЬ ПО», только если Вы знаете, что во временной таблице будет не 1-2 записи. В противном случае эффект может быть обратным — быстродействие от индексированных полей не компенсирует времени построения индекса.
Поддержите нас, расскажите друзьям!
СПРОСИТЕ в комментариях!
1. Что значит «рекомендуется использовать по полям временных таблиц, по которым эта временная таблица будет соединяться с другими таблицами баз данных»? У меня есть левое соединение где в правой части — таблица базы данных. Зачем индексировать временную таблицу если при выборке будет проводиться поиск в правой таблице? То есть индекс временной таблицы в данном случае не функционален.
2. Если я связываю 2 временные таблицы левым соединением, какую таблицу я должен индексировать?
3. В приведённом примере — какой смысл индексировать таблицу по единственному полю, если в индексе получается такое же количество записей как в таблице и (следовательно) обход индекса при выборке занимает примерно столько же времени?
Такое впечатление, что писали статью «чтоб было», не думая.
1. Вы просто индексы готовить не умеете, потому как у Вас поверхностные знания общих принципов применения и работы индексов на платформах БД. Вообще есть определенные стандарты, согласно которым проектировщики платформ БД (вменяемые) следуют, иначе спроса на их платформу не будет.
Так вот ответ на ваш вопрос — раз у вас в левом соединении временная таблица и по ней в самом запросе не идут поиск — значит у вас данные из левой таблицы выводятся в результат запроса (иначе зачем тогда Вам вообще левое соединение). А соответственно соединение по имеющимся записям в левой таблице может идти по ее (левой таблицы) индексу или по поиску (перебору) всех записей этой левой таблицы. И так по каждой строке правой. Да, если записей мало — то результат не так заметен, а то и даже… но когда записей много… Поймите — соединение, какое оно бы ни было — это соединение. И в данном случае можно всю таблицу перебирать, а можно по индексу сработать.
2. Если нужно получить максимально быстро результат выборки, особенно если многократно с этими временными таблицами — то обе. При соединении (не важно каком именно) платформа БД при наличии индекса на поле таблице — работает всегда по индексу. Это всегда быстрее.
3. Автор как раз понимает тему, это Вы не в теме и совершенно не представляете как работают индексы. Да, записей в индексе столько же будет, но принцип работы по индексу совершенно другой. Возможно, если у вас обе таблицы абсолютно аналогично отсортированы по полям соединения — то может и не такой эффект будет — но ведь это как правило не так…
В общем вывод — статью писали думая — это Вы ответили, не подумав…
Сегодня речь пойдет о индексах СУБД MS SQL и их внутреннем устройстве. Я постараюсь рассказать о индексах и с точки зрения СУБД, и с точки зрения 1С 8.3.
Индексы — набор ссылок, упорядоченных по определенным столбцам, создаваемый с целью оптимизации производительности СУБД MS SQL.
Индексы в 1С
В системе 1С индексы создаются двумя способами — явным и неявным образом.
Создание индексов неявным образом:
Платформа создает индексы сама по заранее известным для каждого объекта метаданных ключам данных (ссылка, код, наименование, измерения и т.п.)
Создание индексов явным образом возможна тремя способами:
- Установка флага «Индексировать» у поля (реквизита/измерения). Вариант «Индексировать с доп. упорядочиванием» добавляет в индекс поле «Код» или «Наименование» (прежде всего для динамических списков).
- Добавление поля в «Критерии отбора«.
- Указание индексируемого поля в запрос с помощью конструкции «ИНДЕКСИРОВАТЬ ПО«.
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
Индексы в СУБД Microsoft SQL
Индексы в СУБД MS SQL представляют из себя страницы с данными по 8 Кбайт каждая. Несмотря на то, что индексы призваны улучшить производительность СУБД, у них есть определенные недостатки — они занимают место на диске и замедляют работу СУБД на запись строк.
Виды индексов в СУБД MS SQL:
- Некластерные индексы — такие индексы не перестраивают таблицы, а лишь организуют ссылки.
- Кластерные индексы нужны для построения таблицы в соответствии с индексом. Данные упорядочены, например, по алфавиту. Недопустим для часто изменяющихся столбцов, т.к. СУБД постоянно физически перестраивает таблицу по этому индексу.
- Уникальные индексы — своего рода «надстройка» для кластерных и некластерных индексов. Такой индекс уникален по ключевым полям.
Виды ключей в СУБД:
- Первичный ключ (primary) — набор столбцов, уникально характеризующих строку.
- Внешний ключ (foreign) — поле таблицы, хранящее значение первичного ключа с целью организации связи между таблицами. 1С не использует данный вид ключей.
Важные нюансы использования индексов
Длина ключа индекса в основных СУБД (всех, кроме файлового варианта) — не более 900 байт и 16 различных полей.
Запускайте чаще дефрагментацию индексов на уровне СУБД MS SQL: при частом использовании индексов возможно появление эффекта фрагментации, нельзя допускать уровня фрагментации выше 25%.
Отсутствие индексов может привести к полному сканированию таблицы (table scan), что, в свою очередь, приведет к избыточной блокировке.
Однако не стоит включать индексацию по небольшим наборам данных (например, справочник Организации) — построение индекса может привести к обратному эффекту, быстродействие снизится.
Поддержите нас, расскажите друзьям!
СПРОСИТЕ в комментариях!
«Однако, не стоит включать индексацию по небольшим наборам данных(например, справочник Организации) – построение индекса может привести к обратному эффекту, не уменьшить скорость, а увеличит.».
Видимо ошибка: «… не уменьшить скорость, а увеличит.»
Вы правы. Спасибо большое!
«Внешний ключ (foreign) — 1С не использует данный вид ключей.»
Действительно, эти индексы не используются?
Из литературы вычитал что так, не верно?
Ну почему «Из литературы вычитал»?
Просто странно. По моему, теряются огромные возможности по использованию индексов.
Скорее всего из-за «трудностей перевода» при общении 1С с ms sql.
Согласен, интересно было бы спросить у официальных источников.
И не только с ms sql. У них «хранилищем» могут быть и другие СУБД. Наверное, не надо было изобретать свой язык запросов. Сейчас бы 1С была всеядной в смысле хранилища данных.
Не совсем так. Форэйнкеи в первую очередь нужны для обеспечения целостности данных на уровне СУБД. Так как в 1С используются составные типы данных, т.е в одном поле могут храниться ссылки на праймарикей разных таблиц справочников документов и т.д., то для ФК каждой из этих таблицы пришлось бы использовать отдельное поле, что чревато постоянной реорганизацией таблиц БД.
Недавно столкнулся с такой проблемой: потребовалось обработать большое количество строк (около 1 млн), с последующим left join. Пакетный запрос делал table scan, затем группировал выборку по полям А,Б,С…, выполнял некий отбор. Эти поля и есть поля связи. Сгруппированная выборка связывалась с исходной таблицей, полученной в результате table scan. Рассудив, что неплохо бы проиндексировать эти поля для быстрого поиска, создал индексы в первой и в группированной таблице: индекс(А,Б,С…). Однако, быстродействие вместо того чтобы улучшиться — ухудшилось. Ввиду большого количества строк индексы строился очень долго, занимая примерно 30 процентов времени от общего времени выполнения (судя по плану запроса), а выигрыш в поиске не смог это перекрыть. Без индексов отработало быстрее.
Я что-то сделал не так или можно утверждать, что выигрыш от использования индексов возможен только в случае единичного создания индекса и последующего многократного использования для поиска?
Следующая группа вопросов подобрана из Мастер-групп курсов серии “must have” – это курсы по СКД, запросам и расширениям. Слушатели еще долгое время после прохождения обучения пользуются методическими материалами данных курсов как шпаргалками.
Итак, если хотите узнать, почему в 1С:БП не получается открыть встроенный отчет как внешний, есть ли смысл задавать настройки компоновки для динамического списка и при каких условиях нужно индексировать временные таблицы, то ознакомьтесь с сегодняшней подборкой. Приятного прочтения!
Вопрос №1: Есть ли смысл использовать настройки компоновки для динамического списка?
Если для динамических списков используется СКД, то значит ли это, что запрос динамического списка тоже будет преобразован при выполнении? Имеет ли смысл для динамического списка использовать расширение языка запросов (на закладке “Компоновка данных” конструктора запросов)?
Ответ
- Да, запрос, который извлекает из базы данные динамического списка, тоже может изменяться в зависимости от используемых настроек компоновки.
В одном из занятий курса по СКД мы рассматриваем, как получить исполняемые настройки компоновки для динамического списка.
Например, в типовой конфигурации 1С:БП в форме списка справочника “Контрагенты” используется динамический список с запросом:
Видно, что в тексте запроса есть конструкции в фигурных скобках. Значит, таблицы регистров будут применяться в запросах, если поля из них используются в настройках компоновки.
Вопрос №2: При каких условиях необходимо индексировать временные таблицы?
Хотел бы задать вопрос про индексирование временных таблиц. Рекомендуется индексировать те поля, которые участвуют в условиях отбора или условиях соединения, но в тоже время нельзя бездумно использовать индекс. В связи с этим вопрос: при каком примерном количестве строк нужно индексировать ВТ (временная таблица)? Имеет ли смысл индексировать, если в ВТ будет до 100 строк? Где-то попадалась рекомендация, что нужно индексировать при наличии от 1000 строк.
Ответ
Этот вопрос рассмотрен в статье на нашем сайте – 3 главных вопроса про временные таблицы 1С.
В общем случае рекомендацию можно сформулировать следующим образом – индексирование временной таблицы нужно использовать тогда, когда это дает эффект. Если же индекс не будет использоваться СУБД или наоборот – на индексирование будет потрачено дополнительное время, то индексирование таблицы будет неэффективно. Способ проверки, будет ли использоваться индекс в конкретной ситуации, также приведен в указанной статье.
Вопрос №3: Почему сохраненный типовой отчет 1C:БП не открывается как внешний?
Помогите решить следующую проблему – клиент попросил доработать типовой отчет в типовом решении 1С:БП 3.0, конфигурация на поддержке. Было принято решение сделать отчет внешним, но столкнулся с проблемой. Когда сохраняю отчет как внешний и пытаюсь открыть его через Файл -> Открыть, то появляется ошибка “неизвестный тип объекта метаданных, ВнешнийОтчет.ЗадолженностьПокупателейПоСрокамДолга“. Как победить эту ошибку? В 1С:УТ ред. 11.4 таких проблем не возникает.
Ответ
Причина ошибки заключается в том, что у внешнего отчета или обработки в принципе нет модуля менеджера. А у отчета или обработки из конфигурации такой модуль присутствует.
В 1С:БП в модуле менеджера отчетов есть программный код, а в 1C:УТ – нет. Этим объясняется разница в поведении конфигураций.
При сохранении отчета или обработки во внешний файл модуль менеджера будет потерян. Поэтому нужно учесть этот момент, доработать внешний отчет, например, добавив нужные процедуры в модуль объекта.
Альтернативный вариант – создать расширение, в котором реализовать новый отчет, модуль менеджера в таком случае будет доступен.
Читайте также: