Является ли моя транзакция SQL слишком длинной?

Question

Что-то меня беспокоит о моем приложении. У меня есть SQL-запрос, который объединяет вставки в базу данных в разных таблицах. Я определил, сколько времени требуется для завершения процесса, это занимает около 1,5 секунд. На данный момент я даже не занимаюсь разработкой запроса, у меня все еще есть дополнительные вставки для программирования. Поэтому я полностью ожидаю, что это будет продолжаться дольше, возможно, до 3 секунд.

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

Должен ли я быть обеспокоен этим или я что-то упускаю, когда база данных не будет действовать, как я думаю. Я использую базу данных SQL Server 2014.

Следует отметить, что я приурочил это с использованием объекта StopWatch C# непосредственно перед началом транзакции и остановил его сразу после того, как изменения были зафиксированы. Так что это примерно так же точно, как может быть.

Answer 1

Я думаю, что это зависит от вашего кода, от того, как вы эффективно использовали цикл, выберите запрос и другой оператор.

Answer 2

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

Некоторые общие понятия:
- Убедитесь, что ваши транзакции записи в таблицы в том же порядке
- Держите свои операции как можно более коротким путем подготовки данных для записи как можно больше, прежде чем начать транзакцию.
- Если это новая система (и даже если она не новая), обязательно рассмотрите возможность включения изоляции моментальных снимков и/или Read Committed Snapshot Isolation в базе данных. SI будет (когда явно задано в сеансе) позволяет вашим запросам чтения не блокироваться при одновременной записи. RCSI позволит всем вашим запросам на чтение по умолчанию не блокируется одновременной записью. Но прочитайте это, чтобы понять преимущества и преимущества обоих уровней изоляции: https://www.brentozar.com/archive/2013/01/implementing-snapshot-or-read-committed-snapshot-isolation-in-sql-server-a-guide/