стратегия оптимизации базы данных для очень больших таблиц и дорогостоящих операций удаления - PullRequest
Новая
       12

стратегия оптимизации базы данных для очень больших таблиц и дорогостоящих операций удаления

0 голосов
/ 24 сентября 2018

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

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

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

До сих пор мой подход заключался в удалении лишних строк как таковых: 

SET NOCOUNT ON;
DECLARE @r INT;
SET @r =1;
While @r > 0
    BEGIN
        BEGIN TRANSACTION;
        DELETE TOP (100)
        From [Shift Offer] 
        WHERE offer_timestamp IS NULL
            AND callout_id_fk < 18605 
            AND call_round_id_fk IS NULL
        SET @r = @@ROWCOUNT;
        COMMIT TRANSACTION;
    END

Раньше у меня был установлен Top (1000), что вызвало довольно серьезное снижение производительности.

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

enter image description here

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

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

Так что у меня остается вопрос.Является ли удаление ненужных лишних строк плохим подходом?Можно ли улучшить базу данных, если подумать об индексации нашей оскорбительной таблицы (вместо того, чтобы позволить Azure выполнять индексацию)?Должен ли я выполнять как удаление строк, так и создание индексов?

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

1 Ответ

0 голосов
/ 25 сентября 2018 
select 2
while (@@rowcount > 0)
begin 
     delete top(200)
     From [Shift Offer] 
     WHERE offer_timestamp IS NULL
       AND callout_id_fk < 18605 
       AND call_round_id_fk IS NUL
end
...