По поводу QueryStore. Да можно использовать наверное DynamicsPerf, можно вообще свою таблицу сделать и складывать туда джобом результаты системных хранимых процедур. Просто MS предоставляет встроенный (а не прикрученный сбоку) довольно удобный инструмент с графическим интерфейсом.
Там все основное необходимое присутствует в одном окне. Можно менять период для анализа, смотреть сколько раз запрос выполнялся, какое минимальное время, какое максимальное, какое среднее для каждого плана запроса. Можно менять сам анализируемый показатель - процессорное время, общее время, логическое чтение и т.д. Тут же можно взять готовый план, чтобы сделать план гайд. Вообще это предусмотрено одной кнопкой forcePlan в той же форме, но с аксаптой это не работает, приходится делать по старинке.
Основное полезное применение, если запрос сильно тормозит, то можно зайти в эту форму, он наверняка будет в топе, перейти в анализ запроса, посмотреть на большом периоде какие были планы и сколько в среднем выполнялся с ними запрос и выбрать самый быстрый, создать план гайд.
Правда без граблей тут у МС не обошлось. Во-первых на высоконагруженной базе QueryStore очень сильно растет в размерах. Если у вас маленький размер QueryStore, то она заполнится и станет readOnly, перестанет собирать статистику.
Во-вторых при переключении ноды always on субд считает своим долгом и священной обязанностью скопировать queryStore на новую праймари ноду (и это не отключается, по крайней мере раньше так было, давно не изучал вопрос). Пока копируется queryStore основная база не поднимается и надо ждать. Есть вариант выключить или уменьшить размер query store, но это накладывает блокировки на базу и все равно приходится ждать, хотя вроде и поменьше. Если queryStore маленькая по размеру, то ждать не долго. Но читайте п.1, маленький размер приводит к отказу сбора статистики.
Ну и в-третьих когда база большая, то форма с топ запросами очень долго открывается. Это смешно, но нужно прикрутить план гайд из интернета, чтобы она быстрее открывалась. То есть чтобы оптимизировать запросы нужно оптимизировать вначале инструмент.
По поводу уведомлений из QueryStore. Имеются ввиду в первую очередь уведомления на основе раздела regressed queries. То есть можно настроить уведомление, показывающее те запросы, среднее выполнение которых за текущий период сильно хуже, чем среднее выполнение в предыдущий исторический период. Это свидетельствует о том, что выбран не оптимальный план.
По поводу флагов. На тестовых базах тестировались сами операции. Наличие флагов никто не тестировал, т.к. никто не подумал, что они могут быть просто удалены с сервера. Об этом вообще должны были подумать админы БД, а не аксаптеры, но не подумали. Ошибки бывают. Статья для тех, кто хочет сделать аналогичный переход, чтобы не совершить ошибок.
По поводу расчета кардинальности На сколько я помню там было очень много странных планов, и пришлось много план гайдов сделать, чтобы снять "пожар" начальный. Больше всего такое удивляло. Есть запрос к таблице в 100 тысяч строк с единственным фильтром по полю из некластерного индекса. Тут даже без статистики понятно, что оптимизатор должен сделать index seek по этому полю и далее по результату lookup на кластерный. Но оптимизатор ищет по кластерному. Пересчитываешь статикику фулсканом, ставишь конкретные значения параметров, все равно кластерный индекс. Поведение такое, как будто там 10 строк. При переключении на старый алгоритм все эти странности пропадают.