Уникальный индекс SQL Server по проблеме nvarchar

В конце концов, тайна раскрыта! Думаю, довольно глупая ситуация ..

Проблема заключалась в операторе выбора. В предложении where отсутствовали кавычки, но из-за дьявольского совпадения существующих данных были только числа, выбор не давал сбоев, а просто не выполнялся до тех пор, пока вставки не зафиксированы. Когда были вставлены первые буквенно-цифровые данные, оператор select начал давать сбой: «Ошибка преобразования типа данных nvarchar в числовой»

например, вместо

SELECT [my_nvarchar_column]  
FROM [dbo].[my_table]  
WHERE [my_nvarchar_column] = '12345'

оператор выбора был

SELECT [my_nvarchar_column]  
FROM [dbo].[my_table]  
WHERE [my_nvarchar_column] = 12345

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

Спасибо всем за помощь и извините за довольно глупую проблему!

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

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

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

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

ДОБАВЛЕН

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

ДОБАВЛЕН

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

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

Вы можете добавить подсказку NOLOCK (также известную как READUNCOMMITTED) в свой запрос. Это позволит выполнить «грязное чтение» уже вставленных данных.

e.g.

SELECT [my_nvarchar_column] FROM [dbo].[locked_table] WITH (NOLOCK)

Взгляните на лучшее объяснение здесь:

http://www.mssqltips.com/sqlservertip/2470/understanding-the-sql-server-nolock-hint/

И раздел READUNCOMMITTED здесь:

http://technet.microsoft.com/en-us/library/ms187373.aspx