invmRoust_mВот зашифрованный план по партицированной таблицеПокажите план для


ЗЫ: Анонимайзер планов есть в SentryOne Plan Explorer

Спасибо за подсказку, я предыдущий руками анонимизровал, прилагаю план.

А вот такой же план по не партицированной таблице. Стоимость дерева похожа, а время выполнения все равно быстрее в не партицированной таблице.

alexeyvgRoust_mСтоимость дерева похожа, а время выполнения все равно быстрее в не партицированной таблице.Стоимость - это большая условность, вычисляется исходя из, например, определённой скорости HDD.

А время выполнения разных запросов может быть разная, что тут удивительного?
Они даже разное количество строк возвращают. Хотя вроде бы смотрим разницу одинаковых запросов на одинаковых данных, и разница должна быть только в партицировании.

Далее, если вы ищете по sid:
Roust_mпропущено...

Спасибо за подсказку, я предыдущий руками анонимизровал, прилагаю план.В плане написано INDEX(Column1) ... WHERE Column2=... AND Column3=...
Это ошибка анонимайзера, или ваша? Вроде индекс должен быть по той же колонке, по которой вы ищите (то есть по sid)?



И третье, вам уже писали, повторю ещё раз - если у вас есть индекс по полю, сервер идёт по этому дереву, достаёт записи, какое преимущество будет, если ему указать партицию?

Он всё равно считает те страницы данных, которые нашёл.

Если бы сервер понял, что выгоднее скан, поскольку селективность индекса низкая, то понятно, можно отсканить одну партицию, но если делается поиск, то почему вы ожидаете ускорение?

Это ошибка анонимайзера, на самом деле там и индекс и один из столбцов по sid.

Я пытаюсь понять как можно сервер заставить сканировать одну партицию, или другим способом заставить запрос работать быстрее.

alexeyvgRoust_mЯ пытаюсь понять как можно сервер заставить сканировать одну партицию, или другим способом заставить запрос работать быстрее.Что бы заставить сервер сканировать одну партицию, нужно убрать те индексы, которые позволяют серверу быстро получить данные. тогда сервер свалится в скан.

Попробую объяснить ещё раз.

Вот у вас есть индекс, там указано, что ваши данные находятся на диске в секторе № 123321
Сервер читает сектор 123321, готово!

Далее, вы задаёте вопрос: "как можно сервер заставить сканировать одну партицию"

Вы понимаете, что такой вопрос абсурден, в контексте задачи "прочитать сектор 123321"?

Ну контекст задачи немного шире. Еще одной целью партицирования было собрать все записи по одному и тому же студенту в одной партиции, вместо того, чтобы им быть разбросанными по всей таблице. У одного студента может быть несколько sid. Но pkey есть функция от id студента (st_id). В приложении этот запрос не единственный, поэтому задача заставить это запрос работать на секционированной таблице как можно быстрее. Это на не секционрованной таблице по этому запросу есть индекс где указано, что данные находятся в секторе № 123321. А на секционированной так не получется. Но поскольку секционирование в нашем случае нужно (IMHO), то приодится искать компромисы.

[quot Yasha123]Roust_mпропущено...

ну так соберите их в индексе по pkey,
если запросам это надо.

одно ваше " Всего партиций 15000" заставляется задуматься о неоправданном оверхеде.
вы же своей таблице добавили метаданных больше некуда,
вместо 3 строк allocation units на таблицу типа inrow,row overflow, lob
у вас их 45000.
это не считая индексов, каждый из них еще столько же добавляет.
все это добро надо каждый раз просматривать и оно отгрызет место в buffer pool.
какое уж тут ускорение процесса...
---
ну и у вас что, на каждого студента своя партиция?

Нет, студентов всего около миллиона.

Yasha123а какой у вас объем таблицы в гигабайтах?

На данный момент, пока все еще в зачатаочном состоянии 10ГБ, но в среднесрочтной перспективе 1.5ТБ

invmRoust_m,

План со сканом секции банально дешевле плана с поиском в секции индекса.
Стоимость плана с несекционированным индексом аналогична плану с секционированным.

Можете ради интереса попробовать


Учитывая, что у вас бета 2019-го сервера, не вижу смысла в дальнейших разбирательствах.

Это Azure, я так понимаю, что Майкрософт тестирует на своих клиентах новые версии сиквела. У мне контроля над версией нет.

aleks222Roust_m Но поскольку секционирование в нашем случае нужно (IMHO), то приодится искать компромисы.
Бред.
Сам себе не может объяснить: нахера ему секционирование.
А туда же.
Создает трудности и героически их преодолевает.

Ну хорошо, как тогда в терабайтной таблице данные искать?