Проверяется ли значение первичного ключа перед вставкой быстрее, чем при использовании try-catch?

Question

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

Прямо сейчас я проверяю, есть ли строка сPK существует и вставьте, если нет, но я уже сталкивался с ситуацией, когда строка была вставлена ​​другим процессом в момент сразу после проверки и до фактической вставки, поэтому я думаю об альтернативном способе.

Я не хочу использовать транзакции по соображениям производительности, поэтому я подумал о том, чтобы включить INSERT в try-catch и вообще пропустить проверку.Если строка уже существует, вставка завершится неудачно, но будет заглушена "catch", что нормально.

Мой вопрос - выдает ошибку и перехватывает это дорогостоящая операция?

Answer 1

В SQL 2008 вы можете просто использовать MERGE - намного проще, чем любой из ваших подходов.

Кроме того, я не согласен с вами по поводу «Я НЕ хочу использовать транзакции по соображениям производительности» - каждая выполняемая вами команда DML в любом случае является частью какой-либо транзакции, поэтому существуют транзакции, даже если вы не открываете их явно. Если у вас возникли проблемы с производительностью, вы можете опубликовать более подробную информацию, чтобы получить дополнительную помощь по производительности.

Редактировать: если вам нужны действительно быстрые вставки, не вставляйте по одной строке за раз. Добавьте наборы строк и используйте MERGE - преимущество, которое вы получите от одновременной вставки пакетов строк, значительно превысит любые незначительные улучшения, которые вы получите от оптимизации скорости добавления одной строки.

Во всяком случае, теоретические рассуждения обо всем, что связано с базами данных, обычно недостаточно хороши. Вам действительно нужно тестировать, чтобы определить, что быстрее. То, что вы называете «ненужным запросом существующей строки», может быть совершенно незначительным, и вы не будете знать, так ли это, пока не измерили его в реальных условиях.

Answer 2

Если вы не ожидаете, что сбои будут происходить слишком часто, тогда нормально обрабатывать их с помощью исключений.

Выполнение проверки каждый раз снижает производительность дБ, что также может повлиять на производительность приложения ...

Answer 3

Если вы не используете транзакции, вы должны учитывать вероятность того, что строка может быть вставлена ​​в любом случае, поэтому вы не можете исключить обработку исключений.В лучшем случае вы можете минимизировать редкое исключение, выполнив запрос заранее.Однако стоимость выполнения запроса до каждой вставки, вероятно, будет больше, чем случайное исключение.

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

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

Answer 4

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