так делать не надо)

надо делать oltp-триггер на вставку
и в нем танцевать

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

хотя вопрос про глобальные переменные дискуссионный
тут отдельную ветку вроде даже видел
или еще где-то, не найду теперь)

ну там ничего сверхъестественного
табличка из имени и значения, обертка к ней функциями set и get
ну сейчас это можно сделать связкой топ-псск
еще вариант - отправка сообщений через service broker
блин, так и не найду))) целая статейка потерялась))

на самом деле возможные сценарии могут быть лучше реализованы просто через джоб
там в цикле дергать псск и waitfor ждать немного (если надо)

перепутал, там про массивы и списки
но про переменным тоже можно))

http://www.sql.ru/articles/mssql/03060701arraysandlistsinsqlserver.shtml#fixed-length

но что-то service broker не очень, говорят

https://dba.stackovernet.com/ru/q/32976

ну и, конечно, можно заморочиться на columnstore index
если на триггеры не уходить
на таких задачах где нужно на точное сравнение искать - рекомендовано

только почему-то нужно всё равно ещё задать хэш/ренж индекс
почему - понятно, записи идентифицировать в операциях
но какого черта))) есть же индекс)))

в итоге от затрат на обновление этого второго индекса не уйти вроде бы
(я наглотался всего этого за последние дни, могу подглючивать)

https://docs.microsoft.com/ru-ru/sql/t-sql/statements/create-partition-function-transact-sql?view=sql-server-2017

вишенка на торте в конце холста
поделить лог на секции по одной на каждый день
ну а дальше раз в сутки жать всё предыдущее COLUMNSTORE_ARCHIVE

для идеальной суточной обработки не хватает лишь одного
чтобы одну секцию можно было обозвать активной
и чтобы тогда она была бы in memory
с oltp триггерами и прочей прелестью

впрочем, и сейчас можно соорудить нужное
топ-таблица на прием, по ней триггеры или джобы на перенос/копирование в секционированную архивную

ustass,

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

встречал вариант триггера-счетчика, который просто в отдельной табличке держит итог
и меняет его на каждую операцию

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

из остального - если попробуете, то напишите итог

попробовать сделать составной ключ по нужному полю и ещё одному, желательно уникальному
SELECT COUNT(DISTINCT `field_1`) FROM `table` where K=@k
ну это предположительно чушь, но вдруг все просмотрели))

кроме того, можно предложить вести две таблицы, и брать из каждой число записей как-нибудь быстро
https://stackoverflow.com/questions/6069237/fastest-way-to-count-exact-number-of-rows-in-a-very-large-table/17386344

особенно креативно там ближе к концу параллельно запросы по интервалам индекса
ну в рассматриваемом случае тоже можно иметь составной индекс и кататься по нему

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

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

если покрытие @r1 и @r2 существенное, то есть остальных записей записей немного - то лучше сразу две суммы считать
select (case when K1=@r1 then 1 else 0 end) as a, (case when K2=@r2 then 1 else 0 end) as b
при наличии нужного индекса пройдет параллельно

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

ну то есть он по списку записей будет одинаково гулять считать и в случае с хеш-индексом и в случае некластеризованного
и там будет одинаковое содержимое, видимо ))

про две таблицы

в одной держать всё с K1=@R1
считать K2=@r2 придется всё равно по двум таблицам... или вторую тоже разбить на две))
но по первой считать с вторым фильтром всё равно надо

думаю, вью с подходящим индексом будет хорошо
особенно индексированное вью
https://docs.microsoft.com/ru-ru/sql/relational-databases/views/create-indexed-views

ну собственно вот и рекомендация
когда то я её читал наверное )))

https://docs.microsoft.com/ru-ru/sql/relational-databases/in-memory-oltp/indexes-for-memory-optimized-tables?view=sql-server-2017#duplicate-index-key-values