Оптимизация запроса.

удшщтантон
Дата: 04.02.2009 12:14:52
Товарищи, подскажите почему такая разница в выполении запроса:

Данные:
Таблица credit_base
Rows ~25 млн
Структура:
CREATE TABLE [dbo].[credit_base](
	[id] [bigint] NOT NULL,
	[id_emp] [numeric](22, 0) NULL,
	[evid_srv] [varchar](10) NULL,
	[type_scor] [int] NULL,
	[credit_amount] [numeric](16, 2) NULL,
	[brokerage_per_month] [numeric](20, 4) NULL,
	[date_ratif] [datetime] NULL,
	[date_sign] [datetime] NULL,
	[date_activ] [datetime] NULL,
	[init_pay] [numeric](16, 2) NULL,
	[annuity] [numeric](16, 2) NULL,
	[commision_rate] [numeric](8, 3) NULL,
	[id_product] [bigint] NULL,
	[price] [numeric](16, 2) NULL,
	[insurance] [int] NOT NULL,
	[id_insurance_type] [numeric](10, 0) NULL,
	[id_sellerplace] [bigint] NULL,
	[status] [varchar](1) NULL,
	[spl10_dd] [int] NULL,
	[spl30_dd] [int] NULL,
	[spl60_dd] [int] NULL,
	[spl90_dd] [int] NULL,
	[id_goods] [int] NULL,
	[cat_code] [varchar](10) NULL,
	[id_client] [numeric](22, 0) NULL,
	[client_type] [int] NOT NULL,
	[fdate_statement] [datetime] NULL,
 CONSTRAINT [PK_credit_base] 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]

На таблице имеется индекс:
CREATE NONCLUSTERED INDEX [IND_credit_base_dates] ON [dbo].[credit_base] 
(
	[date_ratif] ASC
)
INCLUDE ( [date_sign],
[date_activ]) WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = OFF) ON [PRIMARY]


При выполнении следующего запроса, выгрузка занимает 3 секунды:
select * from credit_base c
where 
date_ratif between '2009-01-20'  and '2009-01-30'


При объявлении переменных на условие запрос выполняется за 1.5 минуты:
declare @d1  varchar(10), @d2  varchar(10)  
set  @d1='2009-01-20' 
set  @d2='2009-01-30'

select * from credit_base c
where 
date_ratif between @d1   and @d2

Почему такая дикая разница?
Гавриленко Сергей Алексеевич
Дата: 04.02.2009 12:17:10
Потому что план запросов разный.
LSV
Дата: 04.02.2009 12:35:56
Гавриленко Сергей Алексеевич
Потому что план запросов разный.
в первом случае оптимизатор уже знает условия запроса. Во втором случае нет, ибо там параметры.
tpg
Дата: 04.02.2009 12:43:26
Сделайте PRIMARY KEY NONCLUSTERED, а IND_credit_base_dates как раз кластерным (выкинув естественно включаемые столбцы) и посмотрите, что будет.
Либо воспользуйтесь подсказкой оптимизатору, какой индекс в запросе с параметрами использовать.
удшщтантон
Дата: 04.02.2009 20:18:59
Спасибо.

Последий вариант решил проблему.
DeColo®es
Дата: 04.02.2009 22:30:18
Последний - это подсказка?
Самый плохой вариант. Что будете делать, когда индексы захочется "переделать"? Искать по процедурам и/или клиентскому коду хинты?

Вчера помогал запрос оптимизировать.
Изначально был захинтован по самое "немогу". Поудаляли лишние функции и преобразования - сервер сам догадался, что нужно делать безо всяких хинтов.

Кстати, статистику пересчитывали по данной таблице когда последний раз?