Как улучшить подсчет SQL производительность запросов сервера

Question

Размер таблицы 32GB Ряд 250M

Таблица DDL

CREATE TABLE Orders 
(
    ID [int] IDENTITY(1,1) NOT NULL, 
    server [varchar](50) NULL, 
    server_id [int] NOT NULL, 
    merchant_id [int] NOT NULL, 
    order_id [int] NOT NULL, 
    customer_id [int] NOT NULL, 
    customer_name [varchar](50) NULL, 
    [amount] [money] NULL, 
    order_date [smalldatetime] NULL, 
    ship_date [smalldatetime] NULL, 
    order_status [varchar](50) NULL,  
    custom_field_1 [varchar](50) NULL, 
    custom_field_2 [varchar](50) NULL, 
    custom_field_3 [varchar](50) NULL, 
    custom_field_4 [varchar](50) NULL, 
    created_at [datetime] NULL 

    CONSTRAINT [PK_Orders] 
     PRIMARY KEY CLUSTERED ([ID] ASC) 
        WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
          IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
          ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] 

Я следующий некластерном индекс

merchant_id, order_id 
order_date 

Логически order_id, merchant_id сделать уникальный ключ.

Простой запрос, как показано ниже, занимает почти 30 минут.

select 
    sum(amount) 
from 
    Orders 
where 
    Order_Date >= getdate() - 7 

У меня есть несколько вопросов:

• Является ли PK правильно? В настоящее время он находится в поле ID и не используется ни для чего.
• Будет ли делать order_id и merchant_id как помощь ПК в исполнении?
• Каковы идеальные индексы, которые я должен был иметь на этой таблице?

Answer 1

Что вам нужно - это индекс на дату. Создайте некластеризованный индекс на дату, это поможет в производительности. Индексирование очень важно в производительности запросов. Для начала вам нужно иметь индекс в столбце, который сильно используется в разделе where в поле даты вашего случая.

https://www.simple-talk.com/sql/learn-sql-server/sql-server-index-basics/

Answer 2

ли PK правильно?

Возможно. Используя этот суррогат id для кластеризации ключа сохраняет хранения накладных расходов ниже для всех индексов, используя тонкую клавишу 4 байт вместо композитных 12 байт ключа merchant_id, order_id, order_date или 8 байтами ключа merchant_id, order_id ключа

кластеризации как каждый индекс указывает на остальную часть таблицы.

• The Clustered Index Debate Continues… - Kimberly Tripp
• More considerations for the clustering key – the clustered index debate continues! - Kimberly Tripp
• How much does that key cost? (plus sp_helpindex9) - Kimberly Tripp

будет делать ORDER_ID и merchant_id, как PK помощь в исполнении?

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

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

Каковы идеальные индексы, которые я должен иметь на этой таблице?

Вам необходимо просмотреть запросы, планы выполнения и текущее использование индекса, чтобы определить, какие индексы вам нужны для этой таблицы.

---

Поскольку ваш order_date не первый столбец в вашем некластеризованном индекса, оптимизатор будет скорее всего не использовать его для примера запроса.

Даже если у вас есть указатель на order_date, вам нужно будет вернуться к столу, чтобы получить amount. Если вы включите amount в качестве включенного столбца в индекс, он станет индексом покрытия для этого запроса, без необходимости возвращаться к таблице.

Для этого примера запроса, вы могли бы использовать что-то вроде этого, чтобы иметь индекс только запрос, вместо одного с табличным:

create nonclustered index ix_Orders (Order_Date) include (amount); 

Answer 3

Вам просто нужно изменить индекс order_date, сделать его охватывающий индекс, включая колонку «Сумма». То же самое предлагает @Lamark https://www.simple-talk.com/sql/learn-sql-server/using-covering-indexes-to-improve-query-performance/