Что оптимальное индексирует стратегию таблицы отношения?
Ниже для стандартного SQL BigQuery
#standardSQL
SELECT
CONCAT('W', CAST(DIV(DATE_DIFF(t.date, start_date, DAY) + 7, 7) AS STRING)) `date`,
sku,
SUM(sales) sales
FROM `project.dataset.table` t JOIN (
SELECT sku, MIN(t.date) AS start_date
FROM `project.dataset.table` t
GROUP BY sku
) s USING(sku)
GROUP BY sku, `date`
Вы можете проверить, поиграть с выше, используя пример данных из вашего вопроса, как в примере ниже
#standardSQL
WITH `project.dataset.table` AS (
SELECT DATE '2019-02-23' `date`, '123' sku, 20 sales UNION ALL
SELECT '2019-02-24', '123', 33 UNION ALL
SELECT '2019-02-25', '123', 45 UNION ALL
SELECT '2019-02-20', '456', 15 UNION ALL
SELECT '2019-02-22', '456', 23
)
SELECT
CONCAT('W', CAST(DIV(DATE_DIFF(t.date, start_date, DAY) + 7, 7) AS STRING)) `date`,
sku,
SUM(sales) sales
FROM `project.dataset.table` t JOIN (
SELECT sku, MIN(t.date) AS start_date
FROM `project.dataset.table` t
GROUP BY sku
) s USING(sku)
GROUP BY sku, `date`
-- ORDER BY sku, `date`
с результатом
[ 112]3 ответа
Я провел несколько тестов, и вот обновление :
Чтобы охватить все возможные случаи, вам потребуется:
CLUSTERED INDEX (a, b)
INDEX (b)
Это будет охватывать все JOIN sutiations И ORDER BY
Обратите внимание, что индекс на B фактически отсортирован на (B, A) , поскольку он ссылается на кластерные строки.
Пока ваши таблицы a и b имеют идентификатор PRIMARY KEY , вам не нужно создавать дополнительные индексы для handle ORDER BY ASC, DESC .
Подробнее см. запись в моем блоге:
Я провел несколько быстрых и грязных тестов, изучив планы выполнения в SQL Server 2005. Планы показали, что SQL использует кластерный индекс на Aid, Bid для большинства запросов. Добавление индекса Bid (ASC) показывает, что он используется для запросов типа
select * from A
inner join AtoB on Aid = A.id
inner join B on Bid = B.id
where Bid = 1
, поэтому я голосую за решение №3.
Думаю, решение 2 оптимально. Я бы выбрал порядок кластеризованного индекса, глядя на значения и ожидая, какой из них содержит больше отдельных строк. Это идет первым. Также важно иметь индексы уникальных или первичных ключей в родительских таблицах.
В зависимости от СУБД номер 3 может работать так же хорошо, как номер 2. Это может быть, а может и нет. достаточно, чтобы рассматривать значения (ключ кластеризованного индекса) в некластеризованном индексе для чего-либо, кроме ссылки на фактическую строку. Если он может его использовать, то лучше будет номер 3.