Долгосрочные рабочие советы

Question

Я некоторое время работал с SQL-сервером и использовал множество методов повышения производительности для тонкой настройки многих запросов. Большинство из этих запросов должны были быть выполнены в течение нескольких секунд или могут быть минутами.

Я работаю с заданием, которое загружает около 100 КБ данных и работает около 10 часов.

Что нужно учитывать при написании или настройке такого запроса? (например, память, размер журнала, другие вещи)

Answer 1

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

Answer 2

Невозможно сказать, не глядя на запрос. То, что у вас есть индексы, не означает, что они используются. Вам придется посмотреть на план выполнения и посмотреть, используются ли они. Они могут показать, что они бесполезны для плана выполнения.

Вы можете начать с просмотра примерного плана выполнения. Если задание действительно завершено, вы можете дождаться фактического плана выполнения. Посмотрите на параметр сниффинг. Кроме того, у меня был очень странный случай на SQL Server 2005, где

SELECT * FROM l LEFT JOIN r ON r.ID = l.ID WHERE r.ID IS NULL

не завершится, но

SELECT * FROM l WHERE l.ID NOT IN (SELECT r.ID FROM r)

работал нормально - но только для определенных таблиц. Проблема не была решена.

Убедитесь, что ваша статистика актуальна.

Answer 3

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

Сейчас я работаю над аналогичной проблемой, над заданием, которое выполняет сложную бизнес-логику в Java для большого количества записей базы данных. Я обнаружил, что ключ в том, чтобы обрабатывать записи в пакетах и ​​заставлять как можно больше логики работать с пакетами, а не с одной записью. Это минимизирует количество обращений к базе данных и делает некоторые запросы гораздо более эффективными, чем когда я запускаю их для одной записи за раз. Ограничение размера пакета не позволяет серверу исчерпать память при работе на стороне Java. Поскольку я использую Hibernate, я также вызываю session.clear () после каждого пакета, чтобы предотвратить сохранение в сеансе копий объектов, которые мне больше не нужны из предыдущих пакетов.

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

Answer 4

Если возможно, оставьте здесь свой запрос, чтобы было на что посмотреть. Я вспоминаю запрос, который кто-то создал с помощью объединений с 12 различными таблицами, имеющими около 4 миллионов записей, на выполнение которых уходило около суток. Я смог настроить его для запуска в течение 30 минут, исключив ненужные объединения. По возможности старайтесь уменьшить наборы данных, к которым вы присоединяетесь, прежде чем возвращать результаты. Если вам нужно, используйте множество временных таблиц, представлений и т. Д.

В случае больших наборов данных с условиями попытайтесь предварительно применить ваши условия через представление перед вашими объединениями, чтобы уменьшить количество записей. 100K присоединяется к 100k намного больше, чем 2k присоединяется к 3k