Раніше, я розглядав, причини неоптимальною роботи запитів в 1С . Однак, ці дії іноді можуть не допомогти в боротьбі за підвищення продуктивності системи. В цьому випадку, необхідно звернутися до позасистемних засобам аналізу на рівні СУБД, до SQL Server Profiler.
Додаток SQL Server Profiler - це графічний користувальницький інтерфейс для трасування SQL, за допомогою якого програміст 1С може спостерігати за примірником компонента Компонент Database Engine або службами Analysis Services. За допомогою даної утиліти, ми може аналізувати план виконання запиту в покроковому режимі. Додаток дозволяє збирати і зберігати дані про кожну подію в файлі або в таблиці для подальшого аналізу.
Ознаки вибору неоптимального плану запиту СУБД
Як правило, MS SQL підбирає для 1С оптимальний план запиту, але буває СУБД помиляється. Пов'язано це може бути, наприклад, з неактуальною статистикою або високою завантаженістю системи. Програмісту 1С, для того, що б допомогти оптимізаторові будувати правильний план запиту, необхідно перевірити настройку регламентних операція на СУБД MS SQL . Серед ознак неоптимального побудови плану запиту для 1С можуть бути конструкції:
- NESTED LOOPS
- SCAN (TABLE SCAN, INDEX SCAN, CLUSTERED INDEX SCAN)
- SEEK ... WHERE
NESTED LOOPS
Алгоритм з'єднання вкладеними циклами, по суті своїй, це простий перебір двох таблиць і висновок задовольняють з'єднанню рядків. Даний вид з'єднання неприпустимий для провідної таблиці, з великим кількість записів. Однак даний вид з'єднання найпростіший і часто використовується коли СУБД MS SQL не може підібрати інший варіант з'єднання. В цілому, NESTED LOOPS допустимо до використання, коли в провідній таблиці не більше двох записів і швидше за все він швидше відпрацює в такій ситуації.
SCAN
Сканування таблиці або індексу. До цією ознакою відносяться - TABLE SCAN, INDEX SCAN, CLUSTERED INDEX SCAN. Швидкість цього методу дуже сильно залежить від кількості записів в системі. Однак, сканування саме по собі не є помилкою. Сканування може негативно позначатися в випадках коли таблиця містить велику кількість записів, а запит повертає незначна кількість записів. Тобто по суті СУБД даремно витрачає ресурси.
SEEK ... WHERE
Аналог сканування (SCAN), за тим винятком, що сканується частина таблиці, за встановленим умові.