2. Cоединения с виртуальными таблицами

Если в запросе используется соединение с виртуальной таблицей языка запросов 1С:Предприятия (например, “РегистрНакопления.Товары.Остатки() “) и запрос работает с неудовлетворительной производительностью, то рекомендуется вынести обращение к виртуальной таблице в отдельный запрос с сохранением результатов во временной таблице. То есть, следует использовать ту же рекомендацию, что и в случае соединения с подзапросом (см Пункт 1).

Дело в том, что виртуальные таблицы, используемые в языке запросов 1С:Предприятия, могут разворачиваться в подзапросы при трансляции в язык SQL. Это связано с тем, что виртуальная таблица часто (но не всегда) получает данные из нескольких физических таблиц СУБД. Если вы используете соединение с виртуальной таблицей, то на уровне SQL оно может быть в некоторых случаях реализовано, как соединение с подзапросом. В этом случае оптимизатор СУБД может точно так же выбрать неоптимальный план, как при работе с подзапросом, использованным в языке 1С:Предприятия в явном виде.

3. Несоответствие индексов и условий запроса

Условия используются в следующих секциях запроса:

• ВЫБРАТЬ … ИЗ … ГДЕ <условие>
• СОЕДИНЕНИЕ … ПО <условие>
• ВЫБРАТЬ … ИЗ <ВиртуальнаяТаблица>(, <условие>)
• ИМЕЮЩИЕ <условие>

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

• Требование 1 . Индекс содержит все поля перечисленные в условии;
• Требование 2. Эти поля находятся в самом начале индекса;
• Требование 3 . Эти поля идут подряд, то есть между ними не «вклиниваются» поля, не участвующие в условии запроса;

Основные идексы, создаваемые 1С:Предприятием:

• индекс по уникальному идентификатору (ссылке) для всех объектных сущностей (справочники, документы и т.д.);
• индекс по регистратору (ссылке на документ) для таблиц движений регистров, подчиненных регистратору;
• индекс периоду и значениям всех измерений для итоговых таблиц регистров накопления;
• индекс периоду , счету и значениям всех измерений для итоговых таблиц регистров бухгалтерии.

В тех случаях, когда автоматически созданных индексов недостаточно, можно дополнительно проиндексировать реквизиты объекта метаданных в конфигураторе. Однако, следует иметь в виду, что создание индекса ускоряет процесс поиска информации, но может несколько замедлить процесс ее изменения пользователем (добавления, редактирования и удаления) в режиме запуска 1С предприятия. Поэтому индексы следует создавать осознанно и только в том случае, если точно известен запрос, для которого такой индекс необходим. Не следует создавать индексы “на всякий случай” или заведомо избыточные индексы. Например никогда не следует дополнительно индексировать первое измерение регистра, поскольку для поиска по значению первого измерения подходит основной индекс таблицы итогов, который автоматически создаст платформа.

В конфигурации описан регистр накопления ТоварыНаСкладах:

Рис 1. Пример структуры регистра накопления товаров на складах

Платформа 1С:Предприятие автоматически создаст для таблицы остатков данного регистра индекс по периоду и всем измерениям в том порядке, в котором они перечислены в конфигураторе.

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

Запрос 1

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

Варианты оптимизации:

• Проиндексировать измерение «Номенклатура»
• Поставить измерение «Номенклатура» первым в списке измерений. Будьте внимательны при использовании этого метода. В конфигурации могут присутствовать другие запросы, которые могут замедлиться в результате этой перестановки.

Запрос 2

В данном случае нарушено требование 3. Между измерениями «Склад» и «Качество» в структуре регистра находится измерение «Номенклатура», которое не задано в условии запроса. Этот запрос так же не сможет выполняться оптимально. При его выполнении СУБД выполнит поиск по первому полю индекса, но затем вынужденно просканирует некоторую его часть. Сканирование приведет к увеличению времени выполнения запроса и к блокировке избыточных записей в таблице, то есть к снижению общей пропускной способности системы.

Варианты оптимизации:

• Добавить в запрос условие по измерению «Номенклатура»
• Убрать из запроса условие по измерению «Качество»
• Перенести «Номенклатуру» из измерений в реквизиты
• Поменять местами измерения «Номенклатура» и «Качество

Запрос 3

В этом случае требования соответствия индекса и запроса не нарушены. Данный запрос будет выполнен СУБД оптимальным способом. Обратите внимание на то, что порядок следования условий в запросе не обязан совпадать с порядком следования полей в индексе. Это не является проблемой и будет нормально обработано СУБД.

4. Использование логического ИЛИ в условиях

4.1 Использование логического ИЛИ в секции ГДЕ запроса

Не следует использовать ИЛИ в секции ГДЕ запроса. Это может привести к тому, что СУБД не сможет использовать индексы таблиц и будет выполнять сканирование, что увеличит время работы запроса и вероянтность возникновения блокировок. Вместо этого следует разбить один запрос на несколько и объединить результаты.

Например, запрос

ВЫБРАТЬ Товар. Наименование ИЗ Справочник. Товары КАК Товар ГДЕ Артикул = "001" ИЛИ Артикул = "002"

следует заменить на запрос

ВЫБРАТЬ Товар. Наименование ИЗ Справочник. Товары КАК Товар ГДЕ Артикул = "001" |ОБЪЕДИНИТЬ ВСЕ |ВЫБРАТЬ Товар. Наименование ИЗ Справочник. Товары КАК Товар ГДЕ Артикул = "002"

4.2 . Включение пользователей в несколько ролей, каждая из которых имеет RLS

1 С RLS (Record Level Security ) или ограничение прав на уровне записи - этонастройка прав пользователей в системе 1 С , которая позволяет разделить права для пользователей в разрезе динамически меняющихся данных.

Если в конфигурации описано несколько ролей с условиями RLS, то не следует назначать одному пользователю более одной такой роли. Если один пользователь будет включен, например, в две роли с RLS – бухгалтер и кадровик, то при выполнении всех его запросов к их условиям будут добавляться условия обоих RLS с использованием логического ИЛИ. Таким образом, даже если в исходном запросе нет условия ИЛИ, оно появится там после добавления условий RLS. Такой запрос так же может выполняться неоптимально – медленно и с избыточными блокировками.

Вместо этого следует создать “смешанную” роль – “бухгалтер-кадровик” и прописать ее RLS таким образом, чтобы избежать использования ИЛИ в условии, а пользователя включить в эту одну роль.

4. 3 Использование ИЛИ в условиях соединения

Не рекомендуется использовать логическое ИЛИ в условиях соединения, то есть в секции ПО запроса. Это так же может привести к выбору неоптимального плана и медленной работе запроса. Простого универсального способа переписать такой запрос без использования ИЛИ не существует. Следует проанализировать решаемую задачу и попытаться найти другой алгоритм ее решения.

5.Использование подзапросов в условии соединения

Не следует использовать подзапросы в условии соединения. Это может привести к значительному замедлению запроса и (в отдельных случаях) к его полной неработоспособности на некоторых СУБД. Пример запроса с использованием подзапроса в условии соединения:

Запрос. Текст = "ВЫБРАТЬ |ИЗ | Цены.Период В ( | ВЫБРАТЬ МАКСИМУМ(ЦеныПрошлогоМесяца.Период) | ИЗ РегистрСведений.Цена КАК ЦеныПрошлогоМесяца | ГДЕ ЦеныПрошлогоМесяца.Период < НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | И ЦеныПрошлогоМесяца.Номенклатура = ОстаткиТоваров.Номенклатура |) | ГДЕ ОстаткиТоваров.Склад = &Склад" ;

В данном случае подзапрос в условии соединения используется для получения как бы “среза последних” на конец предыдущего периода. Причем, для каждой номенклатуры период может быть разным. Подобный запрос рекомендуется переписать с использованием временных таблиц. Например, это можно сделать следующим образом:

Запрос. Текст = " // Максимальные даты установки цен в прошлом периоде для данных номенклатур |ВЫБРАТЬ | ОстаткиТоваров.Номенклатура КАК Номенклатура, | МАКСИМУМ(Цены.Период) КАК Период |ПОМЕСТИТЬ ДатыПоНоменклатурам |ИЗ | РегистрНакопления.ТоварыНаСкладах.Остатки(...) КАК ОстаткиТоваров | ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.Цена КАК Цены | ПО Цены.Номенклатура = ОстаткиТоваров.Номенклатура И | Цены.Период < НАЧАЛОПЕРИОДА(ОстаткиТоваров.Период, МЕСЯЦ) | СГРУППИРОВАТЬ ПО ОстаткиТоваров.Номенклатура | ГДЕ ОстаткиТоваров.Склад = &Склад; // Выбрать данные по цене за найденный период |ВЫБРАТЬ | ДатыПоНоменклатурам.Номенклатура КАК Номенклатура, | Цены.Цена КАК ЦенаПрошлогоМесяца |ИЗ ДатыПоНоменклатурам | ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.Цена КАК Цены | ПО Цены.Номенклатура = ОстаткиТоваров.Номенклатура И | Цены.Период = ДатыПоНоменклатурам.Период " ;

6.Получение данных через точку от полей составного типа

Если в запросе используется получение значения через точку от поля составного ссылочного типа, то при выполнении этого запроса будет выполняться соединение со всеми таблицами объектов, входящими в этот составной тип. В результате SQL текст запроса чрезвычайно усложняется, и при его выполнении оптимизатор СУБД может выбрать неоптимальный план. Это может привести к серьезным проблемам производительности и даже к неработоспособности запроса в отдельных случаях.

В частности, не рекомендуется обращаться к реквизитам регистратора регистра (например, “ТоварыНаСкладах.Регистратор.Дата”) и т.п. При этом не важно в какой части запроса вы используете реквизит, полученный через точку от поля составного типа – в списке возвращаемых полей, в условии и т.п. Во всех случаях такое обращение может привести к проблемам производительности.

• Избегайте избыточности при создании полей составных ссылочных типов . Указывайте ровно столько возможных типов для данного поля, сколько необходимо. Не следует без необходимости использовать типы “любая ссылка” или “ссылка на любой документ” и т.п. Вместо этого следует более тщательно проанализировать прикладную логику и назначить для поля ровно те возможные типы ссылок, которые необходимы для решения задачи.
• При необходимости жертвуйте компактностью хранения данных ради производительности . Если в запросе вам понадобилось значение, полученное через ссылку, то, возможно, это значение можно хранить непосредственно в данном объекте. Например, если при работе с регистром вам требуется информация о дате регистратора, вы можете завести в регистре соответствующий реквизит и назначать ему значение при проведении документов. Это приведет к дублированию информации и некоторому (незначительному) увеличению ее объема, но может существенно повысить производительность и стабильность работы запроса.
• При необходимости жертвуйте компактностью и универсальностью кода ради производительности . Как правило, для выполнения конкретного запроса в данных условиях не нужны все возможные типы данной ссылки. В этом случае, следует ограничить количество возможных типов при помощи функции ВЫРАЗИТЬ. Если данный запрос является универсальным и используется в нескольких разных ситуациях (где типы ссылки могут быть разными), то можно формировать запрос динамически, подставляя в функцию ВЫРАЗИТЬ тот тип, который необходим при данных условиях. Это увеличит объем исходного кода и, возможно, сделает его менее универсальным, но может существенно повысить производительность и стабильность работы запроса.

Пример

В данном запросе используется обращение к реквизитам регистратора. Регистратор является полем составного типа, которое может принимать значения ссылки на один из 56 видов документов.

Запрос. Текст = "ВЫБРАТЬ | Продажи.Регистратор.Номер, | Продажи.Регистратор.Дата, | Продажи.Контрагент, | Продажи.Количество, | Продажи.Стоимость |ИЗ |ГДЕ...

SQL-текст этого запроса будет включать 56 левых соединений с таблицами документов. Это может привести к серьезным проблемам производительности при выполнении запроса. Однако, для решения данной конкретной задачи нет необходимости соединяться со всеми 56 видами документов. Условия запроса таковы, что при его выполнении будут выбраны только движения документов “РеализацияТоваровУслуг” и “ЗаказыПокупателя”. В этом случае мы можем значительно ускорить работу запроса, ограничив количество соединений при помощи функции ВЫРАЗИТЬ().

Запрос. Текст = "ВЫБРАТЬ | ВЫБОР | ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.РеализацияТоваровУслуг).Номер | ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ЗаказПокупателя).Номер | КОНЕЦ ВЫБОРА КАК Номер, | ВЫБОР | КОГДА Продажи.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг | ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.РеализацияТоваровУслуг).Дата | КОГДА Продажи.Регистратор ССЫЛКА Документ.ЗаказПокупателя | ТОГДА ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.ЗаказПокупателя).Дата | КОНЕЦ ВЫБОРА КАК Дата, | Продажи.Контрагент, | Продажи.Количество, | Продажи.Стоимость |ИЗ | РегистрНакопления.Продажи КАК Продажи |ГДЕ | Продажи.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг | ИЛИ Продажи.Регистратор ССЫЛКА Документ.ЗаказыПокупателя" ;

Этот запрос является более громоздким и, возможно, менее универсальным (он не будет правильно работать для других ситуаций – когда возможны другие значения типов регистратора). Однако, при его выполнении будет сформирован SQL запрос, который будет содержать всего два соединения с таблицами документов. Такой запрос будет работать значительно быстрее и стабильнее, чем запрос в его первоначальном виде.

7. Фильтрация виртуальных таблиц без использования параметров

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

Например, следующий запрос использует секцию ГДЕ запроса для выборки из виртуальной таблицы.

Запрос. Текст = "ВЫБРАТЬ | Номенклатура |ИЗ | РегистрНакопления.ТоварыНаСкладах.Остатки() |ГДЕ | Склад = &Склад" ;

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

Запрос. Текст = "ВЫБРАТЬ | Номенклатура |ИЗ | РегистрНакопления.ТоварыНаСкладах.Остатки(, Склад = &Склад)" ;

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

Такого ускорения просто невозможно добиться аппаратными средствами. Поэтому данной теме необходимо уделить пристальное внимание.

Зачастую, для того чтобы ускорить запрос, необходимо создать свой собственный индекс, и сделать это можно несколькими различными способами.

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

Настройка индексов штатными средствами платформы

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

Индексация с дополнительным упорядочиванием

В видео показано отличие варианта построения индекса Индексировать от Индексировать с доп. упорядочиванием .
На примере показано, какой будет построен индекс платформой при использовании дополнительного упорядочивания.

Создание индекса для измерений регистров

Индексация первого измерения регистров имеет несколько нюансов.
В видео показано, какие индексы создаются для измерений регистров. Также рассмотрена ситуация индексации первого измерения регистра.

По нормам статьи 134 Трудового кодекса РФ работодатели должны обеспечить работникам повышение уровня заработной платы в связи с ростом потребительских цен на товары и услуги. Порядок индексации (с учетом мнения профсоюза) прописывается в коллективном договоре либо в локальном нормативном акте организации. В статье эксперты 1С рассказывают, как в «1С:Зарплате и управлении персоналом 8» редакции 3 провести индексацию штатного расписания и действующих тарифов тарифных ставок сотрудников (с дальнейшим перерасчетом среднего заработка).

Под индексацией в «1С:Зарплате и управлении персоналом 8» (ред. 3) обычно понимают две задачи:

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

Индексация штатного расписания возможна, если в программе «1С:Зарплата и управление персоналом 8» редакции 3 ведется штатное расписание с сохранением истории (установлены флаги Ведется штатное расписание и Ведется история изменений штатного расписания в меню Настройка - Кадровый учет - Настройка штатного расписания).

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

Рис. 1. Индексация штатного расписания которых указаны тарифные группы и разряды (категории), необходимо сначала произвести Утверждение тарифной группы (меню Зарплата - Утверждение тарифной группы).

Для отражения изменения размеров тарифных ставок для тарифных разрядов в штатном расписании в документе Утверждение тарифной группы следует нажать на кнопку Изменить штатное расписание. При этом документ Изменение штатного расписания создается автоматически. Индексация штатного расписания в программе не влечет автоматической индексации заработка сотрудников и не влияет на расчет средного заработка.

Индексация действующих тарифов тарифных ставок сотрудников

Начиная с версии 3.1.3 в программе «1С:Зарплате и управлении персоналом 8» редакции 3 индексация действующих тарифов тарифных ставок сотрудников выражается не просто в увеличении тарифной ставки, а может совмещаться с изменениями и других начис­лений, определяющих состав совокупной тарифной ставки. При этом коэффициент индексации не задается, а рассчитывается как отношение новой совокупной тарифной ставки к прежней. Индексация дейст­вующих тарифов тарифных ставок сотрудников производится документом Изменение плановых начис­лений (меню Зарплата - Изменение оплаты сотрудников - кнопка Создать).

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

Этот флаг доступен в документе, если включена возможность использования механизмов индексации заработной платы флагом Выполняется индексация заработка сотрудников(меню Настройка - Расчет зарплаты). Используя кнопки Подбор или Заполнить, необходимо сформировать список сотрудников, заработок которых подлежит индексации. Далее, по кнопке Заполнить показатели в документе Изменение оплаты сотрудников открывается окно, где можно ввести фиксированные значения (Фикс. значение - см. рисунок 2), или пересчитать предварительно заполненные с помощью математических операций (Прибавить, Умножить на), указав, к примеру, коэффициент, на который следует умножить Оклад, Часовой тариф или другой показатель, определяющие состав совокупной тарифной ставки. По кнопке Приказ об индексации заработка формируется печатная форма приказа об индексации заработка сотрудников.

Если на предприятии Используются тарифные группы, то документ Изменение плановых начислений можно сформировать по кнопке Изменить плановые начисления в документе Утверждение тарифной группы (меню Зарплата - Утверждение тарифной группы).

Отправить эту статью на мою почту

В настоящей статье рассмотрим, как сделать индексация зарплаты в 1С ЗУП сотрудникам организации. Руководствуясь 134 статьей ТК РФ, в которой прописано, что работодателю необходимо обеспечивать повышение зарплаты сотрудникам, поскольку стоимость товаров и услуг периодически увеличивается. Если организация финансируется из бюджета, то индексация также проводится в соответствии с ТК РФ, различными актами или коллективным договором.

Под индексацией зарплаты прежде всего следует понимать увеличение тарифных ставок – окладов, как по всему предприятию, так и по отдельным его подразделениям или филиалам. Значение коэффициента будет в дальнейшем использоваться при расчете отпуска, командировок, среднего заработка и других случаях.

Для проведения индексации зарплаты в 1С ЗУП требуется выполнить ряд шагов в программе. Первое, что необходимо сделать, проверить что выставлены нужные настройки. В разделе “Настройки” выбираем пункт “Расчет зарплаты”. Требуется наличие галочки, что в базе ведется индексация заработка.

Также следует убедиться, что штатное расписание ведется и сохраняется его история. Чтобы проверить наличие данных опций необходимо выбрать пункт “Кадровый учет” и перейти по ссылке “Настройка штатного расписания”.

Для того чтобы произвести индексацию в программе, начиная с релиза 3.1.3, существует специальный документ “Изменение штатного расписания”, который расположен в разделе “Кадры”. Создаем новый документ и заполняем дату с которой будут действовать изменения и организацию. Для заполнения таб. части нажимаем на кнопку “Изменить” и добавляем нужные единицы расписания.

По кнопке “Еще” справа, выбрав пункт “Отображаемые показатели”, можно галочками управлять видимостью показателей и выводить только те в документ, которые требуются. Далее нажимаем на кнопку “Заполнить показатели”, и в открывшемся окне установим коэффициент для показателя “Оклад” равный 1.1.

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

Если у вас есть вопросы по теме Индексация зарплаты в 1С ЗУП, задайте их в комментариях под статьей, наши специалисты постараются ответить на них.

Чтобы отразить сам факт увеличения заработной платы необходимо создать документ “Изменение плановых начислений”, который находится в разделе “Зарплата”, пункт “Изменение оплаты сотрудников”. Поскольку в нашем примере ведется история изменений штатного расписания, то вышеупомянутый документ можно ввести из созданного документа “Изменение штатного расписания” по соответствующей кнопке.

После чего будет создан уже заполненный документ. Обратите внимание, что галочка “Учитывать как индексацию заработка” должна быть установлена.

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

Команда опытных 1с-программистов:

От 5 минут время реакции на срочные задачи, даже в выходные и праздничные дни.

30+ программистов с опытом работы в «1С» до 20 лет.

Делаем видео-инструкции по выполненным задачам.

Живое общение через любые удобные клиенту мессенджеры

Контроль выполнения ваших задач через специально разработанное нами приложение

Официальные партнеры фирмы «1С» с 2006 года.

Опыт успешной автоматизации от небольших фирм, до больших корпораций.

99% клиентов довольны результатами

или

Зачем разработчику 1С «индексировать» измерения регистров и реквизиты?

— Ну у вас и запросы! — сказала база данных и повисла…

Краткий ответ на вопрос заголовка заключается в том, что это позволит выполнять запросы быстро и уменьшать негативное влияние блокировок на .

Что такое индекс?

Оптимизация размещения индексов

При объеме таблиц не позволяющем им «разместиться» в оперативной памяти сервера, на первое место выходит скорость дисковой подсистемы (I/O). И здесь можно обратить внимание возможность размещать индексы в отдельных файлах расположенных на разных жестких дисках .

Подробное описание действий http ://technet .microsoft .com /ru -ru /library /ms 175905.aspx
Использование индекса из другой файловой группы повышает производительность некластерных индексов в связи с параллельностью выполнения процессов ввода/вывода и работы с самим индексом.
Для определения размеров можно использовать выше упомянутую обработку.

Влияние индексов на блокировки

Отсутствие необходимого индекса для запроса означает перебор всех записей таблицы, что в свою очередь приводит к избыточным блокировкам, т.е. блокируются лишние записи. Кроме того, чем дольше выполняется запрос из-за отсутствующих индексов, тем больше время удержания блокировок.
Другая причина блокировок — малое количество записей в таблицах. В связи с этим SQL Server, при выборе плана выполнения запроса, не использует индексы, а обходит всю таблицу(Table Scan), блокируя целиком. Для того, чтобы избежать подобных блокировок, необходимо увеличить количество записей в таблицах до 1500-2000. В этом случае сканирование таблицы становится долее дорогостоящей операцией и SQL Server начинает использовать индексы. Конечно это можно сделать не всегда, ряд справочников как «Организации», «Склады», «Подразделения» и т.п. обычно имеют мало записей. В этих случаях индексирование не будет улучшать работу.

Эффективность индексов

Мы уже отметили в заголовке статьи, что нас интересуют влияние индексов на быстродействие запросов. Итак, индексы наиболее подходят для задач следующего типа:

• Запросы, которые указывают «узкие» критерии поиска. Такие запросы должны считывать лишь небольшое число строк, отвечающих определенным критериям.
• Запросы, которые указывают диапазон значений. Эти запросы также должны считывать небольшое количество строк.
• Поиск, который используется в операциях связывания. Колонки, которые часто используются как ключи связывания, прекрасно подходят для индексов.
• Поиск, при котором данные считываются в определенном порядке. Если результирующий набор данных должен быть отсортирован в порядке кластеризованного индекса, то сортировка не нужна, поскольку результирующий набор данных уже заранее отсортирован. Например, если кластеризованный индекс создан по колонкам lastname (фамилия), firstname (имя), а для приложения требуется сортировка по фамилии и затем по имени, то здесь нет необходимости добавлять инструкцию ORDER BY.

Правда при всей полезности индексов, есть одно очень важное НО – индекс должен быть «эффективно используемым» и должен позволять находить данные с использованием меньшего числа операций ввода-вывода и объема системных ресурсов. И наоборот, неиспользуемые (редко используемые) индексы скорее ухудшают скорость записи данных (поскольку каждая операция, изменяющая данные, должна также обновлять страницы индексов) и создают избыточный объем базы.

Покрывающим (для данного запроса), называется индекс в котором есть все необходимые поля для этого запроса. Например, если индекс создан по колонкам a, b и c, а оператор SELECT запрашивает данные только из этих колонок, то требуется доступ только к индексу.

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