Гость
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Хэш по кластерному уникальному индексу - зачем? / 4 сообщений из 4, страница 1 из 1
10.11.2020, 00:04
    #40016691
Gerros
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хэш по кластерному уникальному индексу - зачем?
Есть сервер:
Код: sql
1.
select @@version


Microsoft SQL Server 2017 (RTM-CU16) (KB4508218) - 14.0.3223.3 (X64) Jul 12 2019 17:43:08 Copyright (C) 2017 Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2019 Datacenter 10.0 <X64> (Build 17763: ) (Hypervisor)

Есть таблица:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE TABLE [dbo].[fact_SALES_TRANSACTIONS](
	[ORDER_DATE] [date] NOT NULL,
	[ID] [bigint] IDENTITY(1,1) NOT NULL,
	[DIVISION] [varchar](2) NULL,
	[SUPPLIER_CODE] [varchar](8) NULL,
	CONSTRAINT [PK_FACT_SALES] PRIMARY KEY NONCLUSTERED (	[ID] ASC)
)

CREATE UNIQUE CLUSTERED INDEX [IX_fact_SALES_TRANSACTIONS_ORDER_DATE_ID] ON [dbo].[fact_SALES_TRANSACTIONS]
(
	[ORDER_DATE] ASC,
	[ID] ASC
)



И есть запрос:
Код: sql
1.
2.
3.
4.
5.
6.
7.
set showplan_text on
select ORDER_DATE, count(1) from [dbo].[fact_SALES_TRANSACTIONS] group by ORDER_DATE order by ORDER_DATE option(maxdop 1)

  |--Sort(ORDER BY:([edw].[dbo].[fact_SALES_TRANSACTIONS].[ORDER_DATE] ASC))
       |--Compute Scalar(DEFINE:([Expr1002]=CONVERT_IMPLICIT(int,[Expr1005],0)))
            |--Hash Match(Aggregate, HASH:([edw].[dbo].[fact_SALES_TRANSACTIONS].[ORDER_DATE]), RESIDUAL:([edw].[dbo].[fact_SALES_TRANSACTIONS].[ORDER_DATE] = [edw].[dbo].[fact_SALES_TRANSACTIONS].[ORDER_DATE]) DEFINE:([Expr1005]=COUNT(*)))
                 |--Index Scan(OBJECT:([edw].[dbo].[fact_SALES_TRANSACTIONS].[PK_FACT_SALES]))



Непонятно, зачем сервер считает хэш?
Что мешает ему просто пройти по кластерному индексу сверху вниз, откладывая каждую новую дату куда-нибудь?
К тому же, даты там лет за десять, то есть их не больше чем 4 тысячи уникальных. Какой смысл считать хэш?

И зачем в конце сортировка? Индекс же уже отсортирован по дате...
_____
* powered by Gerros
...
Рейтинг: 0 / 0
10.11.2020, 02:38
    #40016713
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хэш по кластерному уникальному индексу - зачем?
Gerros,

Непонятно, зачем сервер считает хэш?


хэш он считает потому что выбирает индекс для сканирования не кластеризованный а тот который относится к первичному ключу


Что мешает ему просто пройти по кластерному индексу сверху вниз, откладывая каждую новую дату куда-нибудь?


сколько строк в таблице и сколько уникальных дат? и что там со статистикой на таблице?
...
Рейтинг: 0 / 0
10.11.2020, 10:01
    #40016741
invm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хэш по кластерному уникальному индексу - зачем?
Gerros
Что мешает ему просто пройти по кластерному индексу сверху вниз, откладывая каждую новую дату куда-нибудь?
Желание сэкономить - некластерный просто выгоднее.
Сравните стоимость исходного запроса и
Код: sql
1.
select ORDER_DATE, count(1) from [dbo].[fact_SALES_TRANSACTIONS] with (index = IX_fact_SALES_TRANSACTIONS_ORDER_DATE_ID) group by ORDER_DATE order by ORDER_DATE option(maxdop 1)
...
Рейтинг: 0 / 0
10.11.2020, 18:47
    #40016927
Gerros
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хэш по кластерному уникальному индексу - зачем?
felix_ff, invm, всё правильно говорите. Я в плане выполнения не заметил что он по первичному ключу пошёл. Фактически индекс первичного ключа для данного запроса является покрывающим.
В реальности таблица там довольно широкая, и сканирование кластерного ключа занимает гораздо больше времени, чем проход по первичному ключу.
...
Рейтинг: 0 / 0
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Хэш по кластерному уникальному индексу - зачем? / 4 сообщений из 4, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]