Оптимизация запросов и профилирование
Оптимизация производительности начинается с устранения проблемы N+1 запросов в циклах компонентов и выявления медленных выборок встроенным монитором производительности. Тяжелые запросы исследуются через команду EXPLAIN для исключения полных сканирований таблиц (type: ALL), а новые индексы добавляются с учетом их влияния на скорость пакетных импортов.
Прогресс хранится в этом браузере. Войдите, чтобы сохранить его в аккаунте.
Что нужно понимать
-
1
Анализ через SQL Tracker
-
2
Индексы
-
3
EXPLAIN
-
4
Профилирование
Материалы
Официальная документация
-
Отладка запросов Новая дока
Проверь себя
Заказчик просит «включить кеш» на медленной странице каталога. Почему это не решение?
Кеш прячет медленный запрос до первого сброса: обмен с 1С сбросит тег инфоблока, и страница снова будет собираться четыре секунды. Сначала трекер и счётчик запросов, потом кеш.
Трекер показал две тысячи запросов на странице. Где искать и что делать?
По стеку из SqlTrackerQuery::getTrace(): почти всегда это GetByID() или запрос свойства внутри цикла. Заменить на один GetList() с массивом ID и нужными полями в select.
Монитор предложил индексы для тридцати запросов. Что сломается, если создать все?
Замедлится запись: каждый индекс обновляется при INSERT и UPDATE, на b_iblock_element_property это бьёт по обмену с 1С. К тому же индексы из админки не попадут на стенд без миграции.
Индекс по полю есть, а запрос всё равно перебирает всю таблицу. Почему?
Фильтр LIKE с процентом в начале индекс не использует. Нужен точный фильтр =CODE или where('CODE', ...), либо другой механизм поиска.
Не сходится?
Спросите ассистента BXMax: он знает документацию и материалы сайта по этой теме.
Знаете материал лучше?
Предложите ссылку: после проверки она появится в этом разделе.
Войти, чтобы предложить