Оптимизация больших денормализованных таблиц

Question

У меня есть одна большая денормализованная таблица, которая отражает состав плоского файла фиксированной длины, который загружается ежегодно. 112 столбцов и 400 000 записей. У меня есть уникальный кластеризованный индекс по трем столбцам, которые составляют предложение where запроса, который больше всего выполняется для этой таблицы. Индекс Frag составляет 0,01. Производительность по запросу хорошая, меньше секунды. Однако возвращение всех записей занимает почти 2 минуты. План выполнения показывает, что 100% стоимости приходится на сканирование кластерного индекса (не поиск).

Нет запросов, требующих объединения (из-за денорма). Таблица используется для отчетности. Все поля имеют тип nvarchar (длины поля в файле данных).

Помимо нормализации таблицы. Что еще я могу сделать, чтобы улучшить производительность.

Answer 1

Вот три идеи. Во-первых, если вам не нужен nvarchar, переключите их на varchar. Это уменьшит вдвое требования к хранилищу и должно ускорить процесс.

Во-вторых, убедитесь, что длина полей меньше, чем nvarchar (4000) / varchar (8000). Все, что больше, приводит к тому, что значения сохраняются на отдельной странице, что увеличивает время поиска.

В-третьих, вы не говорите, как вы получаете данные. Если вы возвращаете его в другой инструмент, такой как Excel, или через ODBC, могут быть другие узкие места производительности.

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

Answer 2

Когда вы запрашиваете все строки, вы всегда получаете скан.

400 000 строк X 112 столбцов X 17 байт на столбец - 761 600 000 байт. (Я вытащил 17 из воздуха.) Две минуты, чтобы переместиться на 3/4 концерта по сети, неплохо. Это примерно пропускная способность запланированного резервного копирования моего сервера на диск.

У вас есть деньги на более быструю сеть?

Answer 3

Попробуйте разбить запрос на страницы.Вы можете разделить результаты, скажем, на группы по 100 строк.Таким образом, ваши пользователи увидят результаты довольно быстро.Кроме того, если им не нужно видеть все данные каждый раз при просмотре результатов, это значительно сократит объем извлекаемых данных.

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

Этот пост является хорошим способом начать разбивку на страницы: SQL-запрос разбиения на страницы с порядком на

Просто замените "50" и«100» в ответе, чтобы использовать переменные страницы, и все готово.