|
|
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
Есть индексно-организованная простая табличка Код: plsql 1. 2. 3. 4. 5. Порядка 8 млн записей. Нужно проверить на существование записи с таким ИД, если нет, добавить. Если есть - ничего не делать. Вопрос в производительности. Что быстрее? 1) Селектим из таблицы по указанному ИД, если нет перехватываем exception и добавляем. Код: plsql 1. 2) тоже самое, через агрегат, чтобы избежать exception Код: plsql 1. если n is NULL - добавляем 3) Сразу пытаемся вставить, если не получилось - ну хорошо, идем дальше. Код: plsql 1. Все это часть большого пакета, который дергается в неком общем процессе, после которого работает еще куча таких же больших; поэтому вопрос скорости важен. Что подкажете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 16:13:34 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
Merge ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 16:16:47 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, Хм. Потестил, как мог. Дело в том, что добавление идет в цикле, построчно. Для merge пришлось изворачиваться через cte Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Возможно, я неправильно merge готовлю. Но варианту с лобовым insert и игнорированием исключения он проиграл почти в два раза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 16:56:45 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
aag, Данные откуда идут? Может не нужен цикл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 17:05:48 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
aagДело в том, что добавление идет в цикле, построчно. 1. Избавиться от цикла, если он на базе источника данных. 2. Если цикл суть генератор данных, то можно либо перевести генерацию на запрос, либо заменить построчные операции с БД на подготовку массива с последующим FORALL insert SAVE EXCEPTIONS. В любом случае - если бы абстрактные вопросы производительности имели конкретные ответы, то мир вокруг был бы иным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 17:14:02 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, Этот кусочек со вставкой - малюсенькая часть здоровой процедуры, вызываемой из цикла в другой процедуре, которая вызывается в неком джобе, который запускается... И да, работает это уже по предварительно заполненному массиву данных. В общем, все сложно. Без цикла не обойтись. авторесли бы абстрактные вопросы производительности имели конкретные ответы, Ну, оно так, конечно. С другой стороны, я боялся наткнуться на какие-нибудь нюансы обработки Ораклом исключений в плане производительности. Их в теории желательно было бы избегать же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 17:29:52 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousMergeвсе равно оборачивать в перехват исключения на уникальность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 17:40:03 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
aagЕсть индексно-организованная простая табличка Код: plsql 1. 2. 3. 4. 5. Порядка 8 млн записей. Нужно проверить на существование записи с таким ИД, если нет, добавить. Если есть - ничего не делать. Вопрос в производительности. Что быстрее? Любой select перед insert - это фикция. Или merge или вариант 3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 17:40:53 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
-2-andrey_anonymousMergeвсе равно оборачивать в перехват исключения на уникальность. Ы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 18:21:30 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous-2-пропущено... все равно оборачивать в перехват исключения на уникальность. Ы?в первых двух вариантах проверка селектом не гарантирует невозбуждение исключения. это отличается от третьего варианта, вероятно с ожидаемым для автора поведением. merge по поведению равносилен первым двум вариантам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 19:23:26 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
можно ещё обойтись хинтом в инсерте, ignore_dup_val_on_index, кажется. В 11.2 и выше точно есть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 05:39:58 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
поправка, хинт такой /*+ IGNORE_ROW_ON_DUPKEY_INDEX(tablename, indexname)*/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 10:54:14 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
а вот тут https://iusoltsev.wordpress.com/2013/12/29/ignore_row_on_dupkey_index/ Усольцев показывает, что этот хинт по производительности сливает, а рулит создание view с instead of insert триггером. Но это, конечно, проверить лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 11:28:58 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
ну если уж (из ничего ) пошла такая пьянка, то можно и про (dml) log errors кляузу вспомнить только если сливаться туда будет много строк (10% это много), то скорость сядет на порядок баян ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 11:57:27 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
schi, -2- Если речь идет о том, что кто-то другой может вклинится между селектом и инсертом, то такого кого-то другого нет. Таблицы залочены, это однопользовательский процесс, запускаемый ночью в джобе. А иначе я как-то не могу представить, почему проверка селектом не гарантирует невозбуждение исключения. Nobody1111 В моем случае, этот хинт по скорости совпал с обычной проверкой исключения при инсерте. Но вообще интересно. Провел два теста. В тестовой таблице 1 млн записей, в первом случае шло примерно 10% уже существующих значений (которые должны были быть отвергнуты), 90% новых. Победил с разгромным счетом инсерт с проверкой на исключение. Во втором случае, наоборот 95% добавляемых записей уже были в тестовой таблице, и только 5% новых. Выиграл вариант с проверкой селектом. Мерж отстал немного, где-то на треть. Инсерт провалился с треском - время выполнения было больше почти в 4 раза. ЗЫ. Естественно, тесты выполнялись несколько раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 12:18:33 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
orawish, мне это не совсем нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 12:19:18 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
aagorawish, мне это не совсем нужно. предположу, что в ваших (неестественно тепличных) условиях победит инсерт селект минус ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 12:26:11 |
|
||
|
проверка перед insert на существовании записи
|
|||
|---|---|---|---|
|
#18+
orawishaagorawish, мне это не совсем нужно. предположу, что в ваших (неестественно тепличных) условиях победит инсерт селект минус В конце концов, так и сделал. Вынес из цикла, обернул в мерж. Условия совсем не тепличные, просто это хранилище со своей спецификой. 10 млн записей туда, 20 сюда... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.08.2016, 15:04:02 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39298311&tid=1887587]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
177ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 217ms |
| total: | 483ms |

| 0 / 0 |
