Что быстрее update или insert oracle
Обновлено: 07.07.2024
1) Delete 1 строка, а потом вставка строки с другими значениями в таблицу.
2) Update той же строки в той же таблице "изменить надо два поля" (два значения)
Буду благодарен если объясните почему то или иное дороже. по слухам update всё равно дороже даже учитывая что в 1 варианте два действия.
__________________Помощь в написании контрольных, курсовых и дипломных работ здесь
ON DELETE и ON UPDATE
Доброго всем времени суток! При попытке создания таблицы CREATE TABLE ggroups (id varchar(10).
Trigger INSERT, DELETE
Подскажите как в триггере понять на что он сработал на DELETE или INSERT? Чтоб можно сделать.
Запросы с INSERT, UPDATE, DELETE
Помогите пожалуйста составить запросы на команды с INSERT, UPDATE, DELETE Таблица 1 - Predlozhenie.
UPDATE vs DELETE & INSERT
Есть таблица с несколькими полями, без первичного ключа. По ходу задачи необходимо обновлять.
По поводу почему - это надо много объяснять про архитектуру Oracle, лучше самому почитать том доки "Concepts"
Например, и DELETE, и INSERT приводят к корректировке индексов таблицы, тогда как UPDATE - только если затронуты поля, участвующие в индексе, да и в этом случае будет одна корректировка, но не две.
И DELETE, и INSERT требуют возможной корректировки свободного пространства (свободных блоков) таблицы, а UPDATE -нет.
И т.д. Например, и DELETE, и INSERT приводят к корректировке индексов таблицы, тогда как UPDATE - только если затронуты поля, участвующие в индексе, да и в этом случае будет одна корректировка, но не две.
И DELETE, и INSERT требуют возможной корректировки свободного пространства (свободных блоков) таблицы, а UPDATE -нет.
Не много, но за эту инфу спасибо.
Подскажите Update разве не открывает сначала таблицу типа в режиме edit, вносит изменения потом закрывает и ждёт commit?
Тогда как Delete вроде так не делает, но тоже ждёт commit?
Ну и к примеру из разряда может ли так? Если в таблице 2 поля то update быстрее сработает ежели там было бы 150 полей?
Тот же вопрос и к Delete скорей всего удалить 1 строку с 2 полями быстрее чем с 150 полями?
И это всё не учитвая индексом, constraint, matview и т.д. что влияет на скорость транзакций.
Что-то не сходится всё свершается после того как commit случился.))Что значит?
Один раз "всё"? всё - это много? Сколько это действий?
Допустим, что я возьму за чистую монету про "буфере блоков" даже соглашусь с тем что есть undo и redo ведь как-то откат он делает.
То есть получается, что при delete создаются две записи undo и redo и потом при insert ещё две записи undo и redo
Прошу помощи у Оракл-программистов. Ситуация - нужно импортировать данные из внешнего источника в таблицу. Надо сделать insert или update в зависимости от того, имеется ли уже строка с таким же ключом, как у импортируемой или нет. Цель - максимизировать скорость импорта.
Вижу 3 варианта:
1. Сначала всегда делаем insert, если вылетаем с primary key violation - делаем update.
2. Сначала всегда делаем update, проверяем, обновилось ли что-нибудь (переменная SQL_FOUND), если ничего - делаем insert.
3. Пытаемся найти существующую строку select-ом, в зависимости от результата делаем insert или update.
Сейчас реализован вариант 2. Но может 1 или 3-й лучше по скорости? Или есть еще какие-нибудь варианты?
CTAC_P Уже с Приветом Posts: 6789 Joined: Fri Jun 01, 2001 1:01 amPost by CTAC_P » Wed Jul 16, 2003 1:59 pm
4. Затолкать все не глядя в неиндексированую таблицу, а потом сделать select distinct.
Быстрее это или нет - не знаю. tengiz Уже с Приветом Posts: 4468 Joined: Thu Sep 21, 2000 1:01 am Location: Sammamish, WA
Post by tengiz » Wed Jul 16, 2003 2:17 pm
Post by oMoses » Wed Jul 16, 2003 2:18 pm
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b][i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
Post by oMoses » Wed Jul 16, 2003 2:19 pm
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b][i]А. и Б. Стругацкие, "Пикник на обочине"[/i] Evgen Уже с Приветом Posts: 1219 Joined: Tue Sep 07, 1999 1:01 am Location: Belmont, Ca
Post by Evgen » Wed Jul 16, 2003 4:48 pm
Еще можно создать вьюху на таблице и посадить на нее Instead of insert triggerexception -> update.
снаружи просто инсерт во вьев tengiz Уже с Приветом Posts: 4468 Joined: Thu Sep 21, 2000 1:01 am Location: Sammamish, WA
Post by tengiz » Wed Jul 16, 2003 5:02 pm
FatCat Уже с Приветом Posts: 3153 Joined: Tue Sep 05, 2000 1:01 am Location: RU -> NJ -> MA -> NYPost by FatCat » Wed Jul 16, 2003 5:02 pm
sp123 Уже с Приветом Posts: 1959 Joined: Sat Feb 24, 2001 1:01 am Location: Челябинск -> Everett, WAPost by sp123 » Wed Jul 16, 2003 6:08 pm
Насчет merge сильно рекомендую поискать список багов. Фича свежая и выглядит красиво, но баги там есть достоверно. Какие точно - прямо сейчас сказать не готов, т.к. не пользовался и сходу не нашел, врать не хочу, а тот, кто наступил на граблю, до конца недели в отъезде.
Способы 1 и 2 использую оба, по настроению . 2-й способ имхо лучше, т.к. гарантировнно безгеморройный. Constraint сегодня есть, а завтра его кто-то по ошибке похерил. Виноватого потом найдут, а разбираться с дубликатами потом все равно вам .
Кола Бельды Уже с Приветом Posts: 503 Joined: Wed Jul 09, 2003 5:47 pmPost by Кола Бельды » Wed Jul 16, 2003 10:12 pm
замечательная тема для интервью по ораклу 9.
будет дополнением к моему любимому вопросу про insert for update и stored proc возвращающий resultset
RGoo Уже с Приветом Posts: 1917 Joined: Tue Jul 08, 2003 9:42 am Location: CanadaPost by RGoo » Thu Jul 17, 2003 7:00 am
Yuri_p33 wrote: Надо сделать insert или update в зависимости от того, имеется ли уже строка с таким же ключом, как у импортируемой или нет.
.
Вижу 3 варианта:
1. Сначала всегда делаем insert, если вылетаем с primary key violation - делаем update.
2. Сначала всегда делаем update, проверяем, обновилось ли что-нибудь (переменная SQL_FOUND), если ничего - делаем insert.
3. Пытаемся найти существующую строку select-ом, в зависимости от результата делаем insert или update.
Сейчас реализован вариант 2. Но может 1 или 3-й лучше по скорости? Или есть еще какие-нибудь варианты?
А самый простой вариант, без primary key violation и SQL_FOUND ? См.(индексов я не делал) :
CREATE TABLE a (a1 NUMBER,a2 CHAR(2));
CREATE TABLE B (b1 NUMBER,b2 CHAR(2));
INSERT INTO a VALUES (1,'a1');
INSERT INTO a VALUES (3,'a2');
INSERT INTO B VALUES (1,'b1');
INSERT INTO B VALUES (2,'b2');
UPDATE B SET b2 = (SELECT a2 FROM a WHERE a.a1 IN (SELECT b1 FROM B));
INSERT INTO B (b1,b2)
SELECT a1,a2
FROM a
WHERE a.a1 NOT IN (SELECT b1 FROM B);
- или это слишком долго в вашей ситуации ??
(я не знаю, может у вас там сотни миллионов записей импортируются)
Репутация: 1
Всего: 6
Сабж.Что быстрее-вставлять данные в новую таблицу или изменять их в старой?(При условии что изменяется все/не все)
Чтобы не создавать новую тему,тут же задам несколько похожий вопрос:Что быстрее:Next или MoveBy(1)?
сайт гильдии
Репутация: 3
Всего: 252
INSERT
1.Новую табицу создаёшь
2. Убиваешь старую
3. Присваиваешь новой таблице имя старой (прога же по имени к таблице обращается).
UPDATE
1. Изменяешь записи в старой таблице.
Репутация: 1
Всего: 6
TheSin - небольшое игровое сообщество взрослых и молодых(L2,WoW,Aion,RFonline and other not mmorpg,not computer games).
сайт гильдии
Репутация: нет
Всего: 171
Зависит от многих факторов: базы данных, наличия индексов. К примеру SQL Server может update превратить в последовательность операций - delete/insert.
Индекс соответственно тоже обновляется, при инсерте добавляется новая запись, при апдейте - запись может переместиться вообще не другую страницу.
Влияет также наличие триггера (на инсерте есть, на апдейте нет например), выполняется ли запрос в транзакции.
Репутация: нет
Всего: 2
Вообще, это смотря что за задачу ты хочешь решить. если можно обойтись без создания временной таблицы, то мне кажется лучше просто сделать Update
Репутация: 1
Всего: 6
Разные,согласен,я говорю про их производительность при выполнении одной операции.Я же могу просто обновить(заменить) запись в существующей таблице.Или могу занести новые данные в существующую пустую таблицу.
Чтобы заменить в первом случае пишу
UPDATE T SET a=:a.
Во втором-
INSERT INTO T1(b) VALUE (:b).
Кол-во строк в заполненной таблице-больше 500 тысяч.Индексов нет.
сайт гильдии
Репутация: нет
Всего: 2
Репутация: 1
Всего: 6
сайт гильдии
1. Публиковать ссылки на вскрытые компоненты
2. Обсуждать взлом компонентов и делиться вскрытыми компонентами
Обязательно указание:
1. Базы данных (Paradox, Oracle и т.п.)
2. Способа доступа (ADO, BDE и т.д.)
FAQ раздела лежит здесь!
Если Вам помогли и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, Vit, Петрович.
[ Время генерации скрипта: 0.1099 ] [ Использовано запросов: 21 ] [ GZIP включён ]
Немного теории. В операционных системах UNIX существует раздел файловой системы, который физически находится в оперативной памяти, но позволяет работать с ним как с обычным дисковым накопителем. Скорость доступа к блоку жесткого диска приблизительно равна 1 мс. Скорость доступа к памяти — 0.001 мс. Попробуем применить это к БД MySQL, чтобы выжать максимум из операций insert/update.
Сперва проверим скорость случайной записи на жесткий диск:
Теперь то же самое для shared memory (/run/shm или /dev/shm):
Сравним результаты и увидим, что время создания 1000 файлов уменьшилось в 574 раза. Хорошо. Значит, следует ожидать прирост скорости записи в БД.
1) Проверяем размер и свободное место для /run/shm
2) Проверяем сколько места занимает БД
Значит, что базу мы можем перенести в /run/shm
3) Останавливаем MySQL:
4) Создаем директории и копируем данные:
5) Правим конфиг:
6) Правим AppArmor:
7) Запускаем MySQL
* Если сервис не стартует — смотрим /var/log/mysql/error.log
Теперь самое интересное. Проверяем, что получилось.
Тест на жестком диске я провел заранее, поэтому сразу привожу результаты.
Update выполнялся по случайному интервалу [1 000 000 — 9 000 000] для первичного ключа (id). Крайние значения отброшены, чтобы движок «копался» внутри таблицы.
Существенный прирост скорости на INSERT и еще больший на UPDATE.
Меньше для вставки, т.к. MySQL производит пересчет индексов и организацию данных.
В настройках MySQL выставлено:
innodb_buffer_pool_size = 1024M
Если ставить меньше, то скорость UPDATE для HDD естественно падает.
innodb_flush_log_at_trx_commit = 2
Как таковых транзакций здесь у нас нет и на скорость это не влияет. Тем не менее, оставляем это значение равным 2.
При такой схеме критически важно писать бинарный лог и регулярно делать бэкап. Максимально снизить издержки записи мы можем только указав для бинарника отдельный жесткий диск. Последовательная скорость записи на винчестер намного выше случайной. Поэтому ставим в систему дополнительный жесткий диск, монтируем его, например, в /mnt/hddbin/, и указываем в my.ini путь для бинарного лога: log_bin = /mnt/hddbin/mysql-bin.log
Не забываем добавить скрипты для перезагрузки и останова системы. Смотрим папку /etc/rc*. Обычно это 0 (отключение системы) и 6 (перезагрузка). Мануал, как добавить скрипты легко найти в гугле. Скрипт перед перезагрузкой или выключением системы останавливает MySQL, затем копирует папку /run/shm/mysql-lib на жесткий диск. При включении системы скрипт восстанавливает данные с жесткого диска в папку /run/shm/mysql-lib и после запускает MySQL.
Так же добавляем простенький bash или perl скрипт для мониторинга свободной памяти в /run/shm. Можно подключить Zabbix.
Читайте также: