Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

как увеличить скорость удаления записей [D7, MSSQL]


Страницы:   1 2

redlord ©   (2005-08-18 21:07:00) 

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

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


Alexander Panov   (2005-08-20 21:03:00) [1]

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


redlord   (2005-08-20 20:59:00) [2]

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

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

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


Defunct   (2005-08-20 19:22:00) [3]

DrPass ©   (20.08.05 18:37) [26]

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

Отож.

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

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


DrPass   (2005-08-20 18:37:00) [4]


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


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

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

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


Defunct   (2005-08-20 17:10:00) [5]

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

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

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

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

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


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

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

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


Anatoly Podgoretsky   (2005-08-20 12:13:00) [6]

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

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

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


DrPass   (2005-08-20 10:45:00) [7]


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

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

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

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


Defunct   (2005-08-20 03:04:00) [8]

DrPass ©   (20.08.05 02:38) [21]

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

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

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

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

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

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

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

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


DrPass   (2005-08-20 02:38:00) [9]


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

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


Defunct   (2005-08-20 01:30:00) [10]

> DrPass

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

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


Defunct   (2005-08-20 01:20:00) [11]

DrPass ©   (20.08.05 00:00) [18]

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


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

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


DrPass   (2005-08-20 00:00:00) [12]


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

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


Defunct   (2005-08-19 22:31:00) [13]

sniknik ©   (19.08.05 22:07) [15]

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


> redlord   (19.08.05 22:20) [16]

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


redlord   (2005-08-19 22:20:00) [14]

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


sniknik   (2005-08-19 22:07:00) [15]

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


Defunct   (2005-08-19 21:26:00) [16]

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

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

> тогда что то и прибавки производителности не видно как было 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;


redlord   (2005-08-19 20:01:00) [17]

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


Defunct   (2005-08-19 19:50:00) [18]

redlord   (19.08.05 19:32) [11]

так же само.


redlord   (2005-08-19 19:32:00) [19]

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

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


Anatoly Podgoretsky   (2005-08-19 19:09:00) [20]

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

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


Страницы:   1 2

Наверх

Титульная страница Поиск, карта сайта Написать письмо