Как улучшить производительность на кластерном индексе, ищут
Хорошо, я понял это.
getPage(slug: string) {
return this.apollo
.query({
variables: {
slug: slug
},
query: gql`
query pages ($slug: String) {
pages (where: { slug: $slug }) {
slug,
title,
content,
cover {
name,
url,
},
createdAt,
updatedAt
}
}
`
});
}
7 ответов
Я здесь обобщаю, но...
Поиск кластерного индекса - это, по большей части, лучший сценарий. Единственный способ повысить производительность - это:
- Обновить запрос, чтобы вернуть меньше строк/столбцов, если это возможно;
- Дефрагментировать или перестроить индекс;
- Разбить индекс на несколько дисков/серверов.
Если он возвращает только 138 строк, и это так медленно... может быть, он блокируется каким-то другим процессом? Вы тестируете это изолированно, или другие пользователи/процессы одновременно работают в сети? Или, может быть, это даже аппаратная проблема, например, отказ диска.
Поиск диапазона кластеризованного индекса, который возвращает 138 строк, не является вашей проблемой.
Технически вы можете улучшить производительность поиска, сузив кластеризованный индекс:
- исключить все разнообразие в отдельную единицу распределения, установив 'типы больших значений из строки до 1 и воссоздание таблицы с нуля).
- включить сжатие страниц (только SQL 2008 EE).
И то, и другое может оказать весьма существенное влияние на время поиска диапазона, так как они уменьшают число операций ввода-вывода и увеличивают физическое чтение. Конечно, как обычно, результат будет зависеть от большого числа других факторов, например, от того, какие столбцы вы проецируете (высвобождение прогнозируемого столбца в единицу выделения BLOB может фактически оказать неблагоприятное влияние на некоторые запросы). В качестве дополнительного примечания, обычно фрагментация будет иметь лишь незначительное влияние на такое короткое сканирование. Опять же, это зависит.
Но, как я уже сказал, я очень сомневаюсь, что это ваша настоящая проблема. Вы опубликовали только отдельные части плана и результаты своего собственного анализа. Истинная первопричина может лежать совсем в другом месте.
Вы пробовали какое-то обслуживание этого индекса? Как дефрагментировать? Кажется действительно странным, что это стоит ЭТО много (120,381). Поиск по индексу - самая быстрая операция по индексу, которая не должна занимать так много времени. Вы можете опубликовать запрос?
Что произойдет, если вы жестко закодируете свои критерии WHERE , например:
SELECT StuCertKey, StuKey FROM stu
WHERE stuKey in (/* list 50 values of StuKey here */)
Если это все еще очень медленно, у вас есть какая-то внутренняя проблема. Если он быстрее, то индекс - это не ваше узкое место, это СОЕДИНЕНИЯ , которые вы делаете для создания фильтра ГДЕ .
Обратите внимание, что SELECT * может быть очень медленным, если есть много больших столбцов, и особенно если есть большие двоичные объекты.
Мысли...
Почему IX_Stu кластеризован? Внутри SQL Server добавляет 4-байтовый "уникализатор" к неуникальным кластеризованным индексам. Каково обоснование? Это также раздувает ваш PK
Каков реальный запрос, который вы выполняете?
Наконец, почему FILLFACTOR 80%?
Правка:
"нормальный" FILLFACTOR был бы 90%, но это правило только
Запрос на присоединение? Скорее всего, это ваша проблема. Каковы ваши условия вступления, ГДЕ пункты и т.д.? Каков полный текстовый план?
Некоторые общие советы: когда мне приходится проводить оптимизацию запросов, я начинаю с написания того, каким, по моему мнению, должен быть план выполнения.
Как только я решил, каким, на мой взгляд, должен быть план выполнения, я стараюсь сделать так, чтобы реальный запрос соответствовал этому плану. Приемы для этого разные для каждой СУБД, и не обязательно передавать их из одной в другую, а иногда и между разными версиями СУБД.
Следует помнить, что СУБД может выполнять только одно соединение за раз: она начинает с двух начальных таблиц, присоединяется к ним, а затем берет результат этой операции и присоединяется к следующей таблице. Цель на каждом шаге - минимизировать количество строк в промежуточном наборе результатов (вернее, минимизировать количество блоков, которые необходимо прочитать для получения промежуточного результата, но это, как правило, означает наименьшее количество строк)
.Пересчитать индекс и вычислить статистику?
Единственный способ ускорить процесс - это разбить таблицу на разделы, что может быть или не быть возможным.
.