В данном исследовании мы убедились, что использование кластеризованного индекса, в сравнении с кучей, дает лучшие результаты по всем замеряемым категориям: ЦП, ввод-вывод и время выполнения

При использовании возрастающего ключа индекса и полном отсутствии операций UPDATE

AlwaysOn работает поверх failover cluster'а. В чём отличие:
«Классический» кластер обеспечивает высокую доступность группы ресурсов, в которую входят сервисы SQL Server и общее для узлов хранилище с файлами БД. При отказе основного узла на резервном запускаются сервисы SQL Server, которые обрабатывают файлы БД так же, как при каждом старте (rollforward/rollback) по журналу с диска. Это занимает время.
«AlwaysOn» кластер обеспечивает высокую доступность listener'а, к которому подключаются клиенты. SQL Server запущен на всех узлах, поддерживающих Availability Group. При отказе основного узла переключение на резервный происходит практически со скоростью переноса IP-адреса. Приведение БД в консистентное состояние проходит быстро по данным журнала в памяти.
Активные (на момент сбоя) транзакции теряются в обоих случаях.
Но есть подозрение, что сессии, открытые для чтения (ApplicationIntent=ReadOnly), и работавшие с резервным узлом, могут спокойно продолжать себе работать

Добавлю к каше масла :-). Достаточно попробовать написать schema bound view или функцию в MSSQL, где обязательно указывать имя схемы. И будет не User.Name, а MySchema.User.Name для каждого поля. А ещё табличка с пробелом в названии. Вроде dbo.[Order Details].ProductID. Короткие алиасы весь этот визуальный шум убирают.

И при изменении структуры БД удобнее рефакторить — меньше изменений делать нужно.

Можно использовать десять доступных счётчиков https://msdn.microsoft.com/en-us/library/ms187480(v=sql.110).aspx, они доступны в perfmon'е