Форум: "Базы";
Текущий архив: 2003.06.26;
Скачать: [xml.tar.bz2];
Вниз
UPDATE НА БОЛЬШОЙ ОБЪЕМ ДАННЫХ В INTERBASE Найти похожие ветки
← →
Александр Николаевич (2003-05-30 12:50) [0]Нужна помощь!
Есть следующий запрос на UPDATE.
UPDATE OS_ALLOCACCOUNT A
SET A.DATE_MOVE =
(SELECT D.DATE_MOVE FROM OS_DVIG D WHERE D.ID = A.IDDVIG)
Так вот выполняется БОЛЕЕ 10 мин на хорошей машине.
D.ID - PRIMARY KEY
A.IDDVIG - FOREIGN KEY
OS_DVIG - record count 37 000
OS_ALLOCACCOUNT - record count 5 000
Не очень то и много.
← →
Александр Николаевич (2003-05-30 12:52) [1]Sorry!
Вопрос то забыл написать! Как оптимизировать скорость?????
← →
Zacho (2003-05-30 12:54) [2]Смотри http://www.ibase.ru/devinfo/updsame.htm
← →
Соловьев (2003-05-30 12:54) [3]а ХП не пробовал?
← →
Александр Николаевич (2003-05-30 12:58) [4]А без ХП никак???
А использование Yafill or Firebird никак не помогет? В Yafill можно ведь строить планы на UPDATE
← →
Соловьев (2003-05-30 13:01) [5]
> А без ХП никак???
а что в них плохого?
← →
Ann (2003-05-30 13:03) [6]я тоже считаю, что ХП лучше использовать да и отработает быстрее..
← →
Александр Николаевич (2003-05-30 13:04) [7]Привязываешся к конкретной СУБД. При переходе на другое СУБД(SQL, ORACLE) придется много чего перелопачивать
← →
Zacho (2003-05-30 13:04) [8]
> Александр Николаевич (30.05.03 12:58)
Imho, если это единичная операция, то можно и 10 мин. подождать, а если подобное требуется постоянно, то ХП типа описанных в http://www.ibase.ru/devinfo/updsame.htm - самое то.
← →
Zacho (2003-05-30 13:06) [9]
> Александр Николаевич (30.05.03 13:04)
При переходе на другую СУБД в любом случае придется много чего перелопачивать, иначе получится система одинаково неэффиктивно работающая на всех СУБД.
← →
stone (2003-05-30 13:09) [10]А интербэйз такие кострукции поддерживает?
UPDATE OS_ALLOCACCOUNT
SET DATE_MOVE = D.DATE_MOVE FROM OS_DVIG D INNER JOIN OS_ALLOCACCOUNT A ON D.ID = A.IDDVIG
← →
Александр Николаевич (2003-05-30 13:11) [11]>stone
В том то и дело, что нет
← →
kaif (2003-05-30 17:00) [12]Сама конструкция запроса медленная.
Она проходит 5000 записей в одной таблице и для того, чтобы заменить значение каждый раз вызывает SELECT к таблице, в которой 37000 записей.
Надеюсь, что хотя бы, что поле ID это просто PRIMARY KEY и поиск идет по индексу.
Предлагаю сделать иначе.
Нужно сделать хранимую процедуру, вней конструкцию FOR с объединением таблиц и UPDATE 1 записи внутри цикла.
create procedure quick_update
as
declare variable tmp_id integer; //это уточните
declare variable tmp date;
begin
for select A.ID, D.DATE_MOVE
from OS_ALLOCACCOUNT A, OS_DVIG D
where WHERE D.ID = A.IDDVIG
into :tmp_id, :tmp _date
do
UPDATE OS_ALLOCACCOUNT
SET DATE_MOVE = :tmp_date
WHERE ID = :tmp_id;
end
Здесь использован первичный ключ таблицы OS_ALLOCACCOUNT - условно ID. В вашем запросе он не используется, поэтому я его вынужден был додумать.
Но идея, я думаю, Вам ясна.
Остнется лишь запустить потом процедуру
execute procedure quick_update;
Я думаю, что это должно сработать секунд за 5 - 10.
← →
Zacho (2003-05-30 17:13) [13]
> kaif © (30.05.03 17:00)
На http://www.ibase.ru/devinfo/updsame.htm есть парочка более быстрых вариантов :-)
← →
kaif (2003-05-31 01:16) [14]2 Zacho © (30.05.03 17:13)
Спасибо за ссылку. Очень ценная и компактная статья. Правда там мой вариант приведен (изменение update и select местами). Но я впервые узнал о возможности обращения as cursor. И вообще не знал про поле RDB$DB_KEY. Хотя я пока в сомнении насчет версионного механизма и контекста транзакции. Будет ли это всегда работать (RDB$DB_KEY)?
← →
Zacho (2003-05-31 01:26) [15]
> kaif © (31.05.03 01:16)
Про RDB$DB_KEY могу дать еще пару ссылок http://www.cvalde.com/document/mysteriousDbKey.htm
http://www.cvalde.com/document/practical_use_of_the_rdb.htm
← →
kaif (2003-05-31 05:12) [16]2 Zacho © (31.05.03 01:26)
совершенно потрясающая информация...
именно для задач массовых update-ов.
Но пока мне не удается получить значения RDB$DB_KEY из своих таблиц. Сервер Yaffil ss 821. Все строки select-а возвращают одну и ту же закорюку, причем в каждой таблице свою.
Но я еще поэкспериментирую. Может IBX-ы неверный тип поля используют...
← →
Zacho (2003-05-31 13:34) [17]
> kaif © (31.05.03 05:12)
> Но пока мне не удается получить значения RDB$DB_KEY из своих
> таблиц. Сервер Yaffil ss 821. Все строки select-а возвращают
> одну и ту же закорюку, причем в каждой таблице свою
C помощью IBX или инструмента типа IBExpert и не удастся. Почему - не знаю, я и сам пока плохо понимаю, что такое RDB$DB_KEY и с чем его едят :-)
Попробуй стандартный isql.exe - будешь приятно удивлен.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.06.26;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.023 c
