Sql Server Legacy Database to Clustered index или нет

У нас есть устаревшая база данных, которая является базой данных sql server (2005 и 2008).

Все первичные ключи в таблицах являются уникальными идентификаторами.

Таблицы в настоящее время не имеют кластеризованного индекса, созданного для них, и мы сталкиваемся с проблемами производительности для таблиц с только 750k записями. Это первая база данных, над которой я работал с уникальными идентификаторами в качестве единственного первичного ключа, и я никогда не видел, чтобы сервер SQL работал так медленно с возвратом данных.

Я не уникальный идентификатор - для обеспечения того, чтобы приложение продолжало работать так, как ожидалось.

Цель состоит в том, чтобы улучшить запрос идентификаторов и производительность запросов к объединенным таблицам.

В1: Это улучшит производительность запроса БД или замедлит его?

В2: Есть ли альтернатива этому, которую я не перечислил?

Спасибо Пит

Редактировать: Проблемы с производительностью связаны с быстрым извлечением данных с помощью операторов выбора, особенно если несколько из более «транзакционных / изменяющихся» таблиц объединены вместе.

Редактировать 2: Объединения между Все таблицы, как правило, находятся между первичным ключом и внешним ключом, для таблиц, имеющих внешние ключи, они включены в некластеризованный индекс, чтобы обеспечить более покрывающий индекс.

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

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

Изменить 3: Я бы оценил, что 80% запросов выполняются только по первичным и внешним ключам через механизм доступа к данным. Как правило, наша модель данных имеет лениво загруженные объекты, которые выполняют запрос при обращении к ним, эти запросы используют идентификатор объекта и столбец PK. У нас есть большое количество пользовательских запросов на исключение / включение данных, которые используют столбцы внешнего ключа в качестве фильтра, основанные на критериях для типа X, исключая следующие идентификаторы. Оставшиеся 20% - это когда по столбцам Enum (int) или столбцам диапазона дат выполняются очень немногие текстовые запросы.

По возможности я уже добавил покрывающие индексы, чтобы охватить самые тяжелые запросы, но пока Я все еще разочарован исполнением. Как говорит bluefooted, данные хранятся в виде кучи.