[Из песочницы] Оптимизация загрузки в задаче «Остатки на складах» с помощью секционирования в SQL Server02.06.2017 19:03

Комментарии (9)

  • 2 июня 2017 в 13:48

    +1

    ↑

    ↓

    Как у вас просто всё… Нет территорий, нет мест хранения, нет брака и т.п.…
    Извините, статья хорошая, это крик души просто.

  • 2 июня 2017 в 14:53

    0

    ↑

    ↓

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

    • 2 июня 2017 в 14:55 (комментарий был изменён)

      0

      ↑

      ↓

      В Enterprise редакции — не обязательно, оптимизатор сам найдет ее. В младших редакциях — надо, причем с обязательным указанием with(noexpand)

  • 2 июня 2017 в 16:27 (комментарий был изменён)

    0

    ↑

    ↓ 

    partition by StorehouseID, ProductID
    Поскольку селективность по ProductID лучше (продуктов больше чем складов), может лучше ProductID на первое место поставить, не знаю ускорит ли это работу для группировок или замедлит, но обычно торговые/складские системы делают поиск по условию по товару или набору товаров, а значит ProductID на первом месте должен ускорить поиск/фильтр где в условии есть товар

    • 2 июня 2017 в 16:58 (комментарий был изменён)

      0

      ↑

      ↓

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

      • 2 июня 2017 в 17:18 (комментарий был изменён)

        0

        ↑

        ↓

        уточню, я имею ввиду поиск по кластерному/составному индексу, допустим нам нужно узнать сколько на остатках разных чипсов, но не остальных товаров, пишу: 
        where productId in (1,8,9,101,647) and StorehouseID in (1,5, 7)
        если productId в начале, то это ускорит поиск по индексу, для набора товаров, а не для всех товаров в таблице.
        Если же первым будет StorehouseID у которого плохая селективность, то конечно подходящего индекса для особого ускорения не будет.

  • 2 июня 2017 в 16:39

    0

    ↑

    ↓ 

    count_big(*) qty
    это для чего?

    • 2 июня 2017 в 16:54

      0

      ↑

      ↓

      Без count_big(*) кластерный индекс на представлении с группировкой не создается, ограничение сервера такое.

  • 2 июня 2017 в 18:48

    0

    ↑

    ↓ 

    set dateformat ymd;
declare
	@start  datetime = '2015-02-28',
	@finish datetime = '2015-02-28'

declare
	@start_month datetime = convert(datetime,convert(varchar(9),@start,120)+'1',120)

select @start_month;

    получаю select @start_month; = 2015–02-21 00:00:00.000
    это нормально?

© Habrahabr.ru