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

В любом случае, обработка с удалением -- будет медленно (куча записей в лог, ghost-пейджи в начале таблицы). Только транкейт, только хардкор.

МуМуВот возникла идея писать триггерами с помощью View.Это как минимум промежуточная материализация (в inserted) всего, что заливается в очередь. По мне -- весьма накладно.

МуМуПо идее блокировка на схеме должна быть минимальная.И тем не менее, может стать проблемой, если нет момента, когда никто не льет в очередь данные. Тем более, я не уверен, что можно сделать alter view с блокировкой wait_on_low_priority, как при многих других DDL-операциях. Короче, возможно придется еще как-то городить сериализатор заливальщиков, если таблицы надо нарезать чаще, чем есть возможность заблокировать представление.

Похоже на проблему с ghost-пейджами. Проверяется обычным select top 1 from очередь order by порядок обработки. Если при этом дохрена логических чтений, это оно. Иногда лечится, если удалять c paglock, иногда нет.

МуМу,

Хотя бы. А еще лучше смоделировать пиковую нагрузку и посмотреть, сколько записей в секунду оно тянет, а сколько уже нет. Чтобы через год-другой не пришлось опятьт все переделывать.

Ровно наоборот. В сценарии обработки очереди по чекпоинтам нужен seek на начальную точку выборки, иначе на каждой итерации будет сканироваться вся таблица. В сценарии с удалением, в начале кучи будет образовываться ghost-страницы, которые будуд при каждом delete top или select top вычитываться. Есдинственный сценарий, когда индексы не нужны, это когда таблица обрабатывается сразу челиклм, и сразу же очищается/удаляется.

alexeyvg,

Тогду нужен еще фильтрованый индекс по этому флагу. Плюс апдейт тоже не бесплатный.