tsql, sql express. Как ускорить этот запрос.

← →
12 © (2009-04-27 11:40) [0]

надо срезать БД, поставить это дело на поток (много БД надо срезать)
пишу
declare @Data char(10)
set @Data = "01.01.2008"
delete from journal where document in (select document from document where uredate < @Data)
delete from finjournal where document in (select document from document where uredate < @Data)
delete from document where uredate < @Data

эти 3 таблицы занимают 1,5 - 2 гигабайта
поле document типа GUID
Где-то неделю назад на всех БД сделал дефрагментацию индекса по этим таблицам. Добавление за неделю не должно быть большим ( ну, 1% максимум)
Статистику обновил.

Сейчас выполняется уже 2,5 часа на одной из БД.. Можно быстрее?

← →
clickmaker © (2009-04-27 11:49) [1]

delete from journal
from journal j
inner join document d on j.document = d.document
where d.uredate < @Data

?

← →
Ega23 © (2009-04-27 11:49) [2]

create table #docIDs (id uniqueidentifier); insert into #docIDs (id) select document from document where uredate < @Data; delete from journal where document in (select id from #docIDs); delete from finjournal where document in (select id from #docIDs); delete from document where document in (select id from #docIDs); drop table #docIDs;

Это самое примитивное упрощение, чтобы 3 раза select по дате не делать.

Следующий шаг - сравнение даты не по строке, а по числу (но это надо тип поля смотреть)

А для более реальной оптимизации - надо смотреть структуру БД, какие связи, какие типы столбцов, где какие индексы и т.д.

← →
palva © (2009-04-27 11:56) [3]

> where uredate < @Data

> Добавление за неделю не должно быть большим ( ну, 1% максимум)

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

← →
12 © (2009-04-27 12:03) [4]

спасибо.

>> Ega23 © (27.04.09 11:49) [2]
А намного быстрее будет временную? Просто экспериментировать уже не могу сегодня(уже не с чем), а завтра уже надо на поток ставить

Завтра пораньше приду, попробую еще 2 БД, так и как clickmaker © (27.04.09 11:49) [1] (там с планом сервер долго возился, может и нашел лучший)

ну и вот результат, если что-то прояснит это
delete from journal where document in (select document from document where uredate < @Data)
delete from finjournal where document in (select document from document where uredate < @Data)
delete from document where uredate < @Data
(1985749 row(s) affected)
(514387 row(s) affected)
(262901 row(s) affected)

← →
12 © (2009-04-27 12:05) [5]

>> palva © (27.04.09 11:56) [3]
нет, я удаляю все до 2008 года(более года оставляю)
неделю назад я просто делал дефрагментацию индексов под 0.

← →
Ega23 © (2009-04-27 12:15) [6]

> А намного быстрее будет временную?

а какая разница - временную, или нет? Ты как минимум 3 раза проходишь по таблице document и выбираешь 3 раза одну и ту же информацию.

← →
stas © (2009-04-27 13:29) [7]

12 © (27.04.09 11:40)
У тебя видимо много записей в этих таблицах, для выполнения удаления сначала все пихается в лог транзакций, который у тебя в этот момент растет до больших размеров.
Сделай это удаление за несколько раз удаляя допустим по 5% записей.

← →
12 © (2009-04-28 16:59) [8]

Докладываюсь
Советы от EGA и ClickMaker не очень помогли, не заметно что быстрее хоть сколько-то стало, точных цифр не назову, а на глаз одинаково

а вот Sats навредил :)
Удалялось ощутимо дольше

оставил все как есть. Так понятнее читается.

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

1) может, перед удалением есть смысл удалить индексы/триггеры у таблиц, из которых удаляешь, восстановив их после процедуры удаления? Не уверен, что поможет, но если есть возможность попробовать, почему бы нет?

2) Если данных в таблицах остается сильно меньше, чем удаляется, то может вместо удаления из таблицы сделать так:
- скопировать то, что должно отстаться, во временную таблицу
- сделать trancate table
- вернуть данные из временной таблицы в основную.

drop table journal
drop finjournal
drop document
Пересоздай быстро и эффективно

2) Если данных в таблицах остается сильно меньше, чем удаляется, то может вместо удаления из таблицы сделать так:
- скопировать то, что должно отстаться, во временную таблицу
- сделать trancate table
- вернуть данные из временной таблицы в основную

мда, это надо проверить..
еще и palva об этом намекал
но мне кажется, там фифти фифти как раз. Тем более sql-express, там на БД ограничение.

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

Проиндексируй по полю uredate все таблицы о индексам он побыстрее шустрит

tsql, sql express. Как ускорить этот запрос. Найти похожие ветки