Содержание:

1.       Общие рекомендации для запросов СУБД

2.       Рекомендации для работы с запросами в 1С

3.       Примеры оптимизации запросов.

   

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

 

В клиент-серверной архитектуре платформа 1С транслирует запрос, созданный разработчиком в запрос к базе данных на языке запросов SQL. Оптимизатор запросов СУБД (а язык запросов 1С поддерживает работу со следующими СУБД: MSSQLServer, PostgreSQL, IBMDB2, Oracle Database) строит план запроса. План запроса можно посмотреть средствами самой СУБД.  

 

1.    Общие рекомендации для запросов СУБД:

 

·         В запросе нужно стремиться выбирать только необходимые поля.

·         Пакетирование запросов (использование временных таблиц) повышает их читаемость. Объемный запрос может привести к выбору неоптимального плана оптимизатором запросов (на стороне программы СУБД).

·         В соединении (двух таблиц) не следует использовать подзапросы.

·         Не следует использовать в одном запросе много таблиц, поскольку оптимизатор запроса может выбрать неоптимальный план.

·         Никогда не использовать запросы в цикле.

·         Отсутствие значений параметров в виртуальной таблице или использование вместо них условия «ГДЕ»

·         Отсутствие проверки на NULL

·         Не получать данные через точку от полей ссылочного типа.

    

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

 

2.    Рекомендации для работы с запросами в 1С

 

Вот некоторые рекомендации, необходимые для оптимизации запросов:

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

 

Если в условии есть индексированный столбец, то лучше комбинировать равенства и неравенства. Например, лучше писать значение_колонки>= 8, чем значение_колонки>7. Так как в последнем случае сначала будет найдено число 7, а затем будет производиться поиск следующих значений. В первом случае поиск сразу начинается с 8.

 

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

 

Часто объединение запросов бывает лучше, чем один запрос, поскольку отдельные запросы получаются проще и лучше поддаются оптимизации. К тому же в некоторых СУБД отдельные запросы выполняются параллельно.

    

Использование индексов имеет некоторые недостатки. На них расходуются следующие ресурсы:

 

·         Индекс сам по себе занимает место (дополнительно к тому, что занимает таблица).

·         При извлечении из таблицы большого числа строк использование индекса – только потеря времени. Это несколько замедлит исполнение.

·         Разработчику необходимо решить, использовать ли индекс в зависимости от следующих моментов.

·         Как часто будет выполняться запрос к таблице и как часто она будет обновляться.

·         Насколько медленно выполняется запрос.

·         Что в данном случае важно: время исполнения или место на диске. Обычно время более ценно.

·         Как часто поля, которые будут индексироваться, будут использоваться в условиях запроса.

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

 

3.    Примеры оптимизации запросов.

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

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

 

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

 

Также рекомендуется настроить очистку процедурного КЭША и процедуру дефрагментации индекса.

В процессе работы с базой данных происходит эффект фрагментации индексов.

Рекомендуется выполнять дефрагментацию индексов не реже одного раза в неделю.

   

Специалист компании ООО «Кодерлайн» 

Ильдар Мингалеев.