Инструкция DELETE зависает на SQL Server без видимой причины

Edit : решено, на столе был триггер с петлей (читайте мой собственный ответ ниже).

---

У нас есть простой оператор delete, который выглядит следующим образом:

DELETE FROM tablename WHERE pk = 12345

Это просто висит, никакого тайм-аута, ничего.

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

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

Мы запустили DBCC CHECKDB против него, и он сообщает 0 ошибок.

Глядя на результаты sp_who и еще sp_lock пока запрос висит, я замечаю, что мой spid имеет множество замков PAG и KEY, а также случайный замок TAB.

Таблица содержит 1.777.621 строк, и да, pk является первичным ключом, поэтому это удаление одной строки на основе индекса. В таблице отсутствует сканирование. план выполнения, хотя я замечаю, что он содержит что-то, что говорит таблица Spool (нетерпеливый Spool), но говорит предполагаемое количество строк 1. Может ли это на самом деле быть скрытым сканированием таблицы? Он только говорит, что смотрит на столбец первичного ключа.

Попробовал DBCC DBREINDEX и обновить статистику по таблице. Оба завершены в разумные сроки.

К сожалению, в этой конкретной таблице имеется большое количество индексов. Это основная таблица в нашей системе, с большим количеством столбцов, и ссылки, как исходящие, так и входящие. Точное число-48 индексов + кластеризованный индекс первичного ключа. На что еще нам следует обратить внимание? Заметьте также, что эта таблица не имела этой проблемы раньше, эта проблема возникла неожиданно сегодня. У нас также есть много баз данных с одинаковыми настройками таблиц (копии клиентских баз данных), и они ведут себя так, как и ожидалось, именно это и является проблематичным.