как увеличить скорость удаления записей

← →
redlord (2005-08-18 21:07) [0]

всем привет
народ подскажите можно ли увеличить скорость удаления записей из таблицы
а то у меня удаление 10000 записей занимает порядка 30 секунд
я использую sql запрос типа : delete from ... where ... для удаления всех не нужных записей одним запросом.

P.S. mssql сервер и моя прога запущены на одном компе

← →
Джо © (2005-08-19 06:08) [1]

Дропни тригеры перед удалением, затем включи. Отключи индексы.

← →
Sergey13 © (2005-08-19 09:20) [2]

Я бы в таком вопросе был поосторожнее с тригерами и индексами. Если они есть, то наверное неспроста.
Можно попробовать удалять пачками (например по 1000 штук).
Если это разовое удаление - 30 секунд фигня. Если это требуется часто, то это повод задуматься о проектировании. ИМХО.

← →
Anatoly Podgoretsky © (2005-08-19 09:36) [3]

Кроме триггеров важна часть WHERE и наличие ресурсов у компьютера.

← →
Ega23 © (2005-08-19 09:54) [4]

если в where стоит какой-нибудь вложенный Select, то ситуация вполне может быть.
Рекомендую взглянуть в сторону "ночного аудита системы". Т.е. если это очистка мусора, то проводить её, допустим в 3 часа ночи, когда система наиболее разгружена.

← →
MOA © (2005-08-19 10:01) [5]

А может просто - либо нет индексов по полям в WHERE - либо, наоборот, излишне много индексов?
Вариант - оператор не в процедуре/функции? Не динамический?
Если условие в WHERE не черезчур громоздко - возможно, будет полезно на него взглянуть.
Удачи!

← →
Anatoly Podgoretsky © (2005-08-19 10:03) [6]

MOA © (19.08.05 10:01) [5]
Нельзя - это самая секретная часть вопроса, не считая триггеров.

← →
redlord (2005-08-19 17:10) [7]

to анатолий
по прозьбе МОА снимаю гриф совершенно секретно
1 в таблице нет индексов все поля не индексированы
2 процедура удаления выполняется примерно раз в час но етот комп
является игровым сервером локальной сети а удаление грузит машину на 100 процентов

3 строку delete from ... where ... читать как
delete from mytbl where ip= 192.168.75.6

← →
MOA © (2005-08-19 17:44) [8]

>все поля не индексированы
Вот поэтому и
>удаление грузит машину на 100 процентов
и
>удаление 10000 записей занимает порядка 30 секунд
Дело в том, что сервер при отсутствии индекса просматривает всю таблицу - каждую запись, от первой до последней. Если таблица большая - всю её в кэш сервер считать не сможет - и своп тормозит машины ещё быстрее (поэтому 100% загрузки - страницми VM шелестик аж караул ;)).
Сделайте индекс по ip - скорость значительно возрастёт.
Удачи!

← →
Anatoly Podgoretsky © (2005-08-19 19:08) [9]

redlord (19.08.05 17:10) [7]
1 в таблице нет индексов все поля не индексированы

И ты еще жжешь скорости?

← →
Anatoly Podgoretsky © (2005-08-19 19:09) [10]

redlord (19.08.05 17:10) [7]
3 строку delete from ... where ... читать как
delete from mytbl where ip= 192.168.75.6

Где здесь 10000 записей?

← →
redlord (2005-08-19 19:32) [11]

TO Анатолий
так как поле ip не первичный ключ одинаковых записей могет быть сколько угодно.

во блин гнижку по sql на работе забыл а с индексами ешо ни разу ни чего не делал народ подскажите как будет выглядеть мой запрос
на удаление всех записей где поле ip = 192.168.75.6 .
полю ip присвоен индех с именем "index_ip"

← →
Defunct © (2005-08-19 19:50) [12]

redlord (19.08.05 19:32) [11]

так же само.

← →
redlord (2005-08-19 20:01) [13]

то defunct
при индексировании поля текст запроса не меняется ?
тогда что то и прибавки производителности не видно как было 30 сек так и осталось

← →
Defunct © (2005-08-19 21:26) [14]

> при индексировании поля текст запроса не меняется ?

абсолютно ничего не меняется, просто СУБД выполняет поиск быстрее, т.к данные при наличии индексов сортируются.

> тогда что то и прибавки производителности не видно как было 30 сек так и осталось

Установи тип поля IP в Integer.
Функции преобразования:

function StrToIp( IpStr: String ): Integer; var S1, S2: String; PosT : Integer; i : integer; begin S1 := IpStr; Result := 0; for i := 1 to 4 do begin PosT := Pos(".", S1); if (PosT = 0) and (i < 4) then raise EConvertError.Create("invalid IP"); if i < 4 then begin S2 := Copy( S1, 0, PosT - 1); S1 := Copy( S1, PosT+1, Length( S1 ) - PosT + 1 ); end else S2 := S1; try Result := (Result shl 8) + StrToInt( S2 ); except on E:Exception do begin E.Message := "invalid ip (string=" + S2+")"; raise end end end end; function IpToStr( Ip : Integer): String; type TIPRecord = record B1, B2, B3, B4: byte; end; begin Result := IntToStr( TIpRecord( ip ).B4 ) + "." + IntToStr( TIpRecord( ip ).B3 ) + "." + IntToStr( TIpRecord( ip ).B2 ) + "." + IntToStr( TIpRecord( ip ).B1 ); end;

← →
sniknik © (2005-08-19 22:07) [15]

Defunct © (19.08.05 21:26) [14]
> Функции преобразования:
...
Uses WinSock;
function inet_ntoa(inaddr: TInAddr): PChar;
function inet_addr(cp: PChar): u_long;

← →
redlord (2005-08-19 22:20) [16]

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

← →
Defunct © (2005-08-19 22:31) [17]

sniknik © (19.08.05 22:07) [15]

;>
не думаю что мои намного хуже.

> redlord (19.08.05 22:20) [16]

ты же удаляешь по IP, соответственно ускорение получишь в том случае, если поле будет численным, а не строковым.

← →
DrPass © (2005-08-20 00:00) [18]

Defunct © (19.08.05 22:31) [17]
> ты же удаляешь по IP, соответственно ускорение получишь
> в том случае, если поле будет численным, а не строковым

Как правило, сравнение строк в БД выполняется практически с той же скоростью, что и сравнение чисел (бывает даже наоборот, строковые сравнения выполняются быстрее). Там механизм посложнее, чем "cmp ax, cx"

← →
Defunct © (2005-08-20 01:20) [19]

DrPass © (20.08.05 00:00) [18]

> Как правило, сравнение строк в БД выполняется практически с той же скоростью.

Не в этом случае. Сравнение возможно действительно будет быстрее если сразу определяется неравенство, как, например, для строк "Арбуз" и "Букет", по первому же символу.

Для IP же, практически все символы старшей части схожи, и при сравнении придется пробегаться по всей строке. Если же мы IP преобразуем в численный вид, то все сведется к cmp [ecx], eax.

← →
Defunct © (2005-08-20 01:30) [20]

> DrPass

сравнить
"192.168.75.6"
с
"192.168.75.6"
как минимум 12 команд, в то время как сравнить
С0A84B06
и
С0A84B06
как минимум на 11 команд меньше.

Умножаем число команд на количество записей с таким IP, и имеем существенный выигрыш в скорости.

> Defunct © (20.08.05 01:30) [20]

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

DrPass © (20.08.05 02:38) [21]

смотрим сабжевый вопрос..

> 10000 записей занимает порядка

10k * 11 = 110 тыс операций с памятью, для вас несуществено? Их можно просто избежать. +Размер записей сократится, на, всреднем, 8 байт, что позволит использовать меньшее число страниц для того же числа записей.

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

Вы пишите такую откровенную чушь, я от вас такого не ожидал..

> Не верите - сами проэкспериментируйте.

уже эксперементировал, и в базе у меня тип IP поля строго integer.

Да и еще, коль мы заговорили о страницах, то автору поста также было бы полезно проверить размер страницы, и установать как можно больше.

> 10k * 11 = 110 тыс операций с памятью, для вас несуществено?
> Их можно просто избежать. +Размер записей сократится, на,
> всреднем, 8 байт, что позволит использовать меньшее число
> страниц для того же числа записей.

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

> уже эксперементировал, и в базе у меня тип IP поля строго
> integer.

Я же тоже только что не придумал DrPass © (20.08.05 02:38) [21] - все это проверялось опытным путем

Defunct © (20.08.05 03:04) [22]
Размер страницы фиксирован = 64 кб

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

У автора по его словам удалениее 10000 записей занимает 30 секунд, это говорит, что у него что то не в порядке в системе, это слишком много. У меня ежемесячное одноразовое удаление 500 000 щаписей занимает меньше времени.

> DrPass © (20.08.05 10:45) [23]

> Во-вторых, пропускная способность памяти - 3-6 гигабайт в секунду, скорость процессора - несколько миллиардов операций в секунду.

Это спорный вопрос, мы с вами не знаем какую машину использует redlord.

> Даже 110 тысяч операций - это несущественно.

Тем не менее их можно просто избежать. Не думаю что это повредит как-то.

Anatoly Podgoretsky © (20.08.05 12:13) [24]

> Сделав поле числовым возможно ускорим точное сравнение, но замедлим или полность потеряем частичное сравнение, что характерно для сетей.

не вижу такой ситуеации. маска сети как правило затрагивает старщую часть interger представления, и неточные сравнения попросту не требуются или сводятся к x0 < Ip < x1.

> Defunct © (20.08.05 17:10) [25]

> Тем не менее их можно просто избежать. Не думаю что это
> повредит как-то.

Повредит, конечно. Например, ты не сможешь работать с такой таблицей через консоль SQL или любую другую утилиту администрирования БД. Вернее, работать-то сможешь, но представленная в числовом виде информация для тебя будет бесполезным грузом. Удобство работы стоит пары миллисекунд процессорного времени?
> Это спорный вопрос, мы с вами не знаем какую машину использует
> redlord

А какую? 386DX40? Не думаю. А машина класса P2 уже без проблем справится.
Я же не против такой оптимизации. Просто в данном случае она не нужна, и не она является причиной "торможения".

DrPass © (20.08.05 18:37) [26]

> Я же не против такой оптимизации.

Отож.

> Просто в данном случае она не нужна, и не она является причиной "торможения".

Может быть, если вы можете указать еще какой-нибудь способ ускорение, то пожалуйста, я буду только рад выслушать полезные советы.

← →
redlord (2005-08-20 20:59) [28]

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

как будет выглядеть запрос на удаление тока 10 записей, где
ip=192.168.75.6
чтоб выполнять его циклично(внутри проги) пока не будут удалены все записи где ip=192.168.75.6

p.s. все ето безобразие запускается !сейчас! на celeron 1.5

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

как увеличить скорость удаления записей Найти похожие ветки