Интересная онлайн конференция намечается, доклады должны быть интересными: https://eightkb.online/

Спасибо большое

Добрый день! Меня Константин зовут, я Hr компании.
Сейчас появилась потребность в повышении навыков Команды разработки, а точнее с SQL. Знаете ли вы какие то серьёзные курсы, которые могли бы порекомендовать?

Добрый день, могу порекомендовать вам корпоративное обучение от Сергея Олонцева

А где об этом можно почитать?

Спасибо, связался!
Есть еще рекомендации?

Книжки им купите по той области что нужна. Лучше ничего не придумаете.

На sql-ex.ru их отправьте, пусть головы ломают )))

ну тогда не книжки, а конкретные задачи по SQL.

ну да, вообще с этого стоит начать - какие задачи они будут решать.

а можно как то подробнее? какие навыки скуля хотите повысить?
ну так ради интереса

Подскажите пожалуйста, была таблица с кластерным индексом по Id (тип INT NOT NULL). Секционировал таблицу по колонке со временем FinalTime(тип DateTime NULL).  Кластерный индекс стал по Id и FinalTime. Есть ли большая разница, чтобы на первое место в кластерном индексе поставить FinalTime а потом Id ?  
На таблице есть и некластерные индексы выровненные по FinalTime, в частности на колонку Inserted(DateTime NOT NULL). Проблема в том, что после секционирования стали возникать часто блокировки в запросах вида Select Top 100  * ... Order by Inserted

На плане выполнения запроса делает Key Lookup из кластерного индекса 50% 120К записей и Index Scan из некластерного индекса покрывающего запрос 3%, 120К записей. + Сортировка 47%

спасибо )

Может глупый вопрос, но пробовали select (nolock) ? Если не критичен уровень изоляции транзакции

Вопрос больше в продуктивности поиска. Очень долго выполняется запрос, хотя индексами покрыт. Nolock не повышает скорость выполнения.

Минуту может крутиться запрос. Хотя должен выполняться не больше секунды. А само секционирование добавлялось, чтобы быстро удалять записи перенесённые в ОЛАП и не возникало блокировок при удалении записей.

давайте начнем с теории, зачем вообще нужно партиционирование и какие преимущества оно дает:
1. когда вы включаете в кластерный индекс надо добавить колонку по которой происходило партиционирование, это позволяет оптимизатору, на основании функции партиционирования, делать точечный запрос по партициям, если присутствуют необходимые условия в предикатах.
2. вы можете объединять\исключать\добавлять партиции в этот момент оптимизатор использует блокировку уровня SCH-M,  с одной стороны это происходит быстро с другой стороны такие суперблокировки не совместимы
3. вы монете использовать не выровненные индексы, которые будут построены на разных партициях, но тогда забудьте о switch partitions, т.к. это работает только с выровненными индексами
4. Появляется новый уровень эскалации, если раньше у вас были RID,Page,Extents,Table,  то появится новый уровень Partition
5. Вы можете положить разные партиции в разные файловые группы на разные и тем самым задействовать утилизацию несколько дисков одновременно и делать бэкапы по файловым группам например.
6. Можно установить разные уровни сжатия для разных партиций.

ну и конечно же нужен сам запрос  и его план, у всех местных хрустальные шары давно потеряны

Привет. Вопрос банальный:
Насколько большая разница в производительности между
1) inner join (фильтр)
2) in (фильтр)
3) exists

Какой вариант каноничный