Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 FORCESEEK: Это хорошо или плохо?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
На простом объединении мастер-детайл таблиц заметил (SQL2012), что запрос выполняется секунд 10, посмотрел план, вижу, что там
clustered index scan на ПК поле.

Поставил хинт FORCESEEK - стало меньше секунды.

Вопрос: FORCESEEK - это хорошо или плохо?
Какие минусы?

(Сервер версия: 2008 - 2016)
25 янв 17, 14:24    [20144593]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Ролг Хупин,

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

автор
Поскольку оптимизатор запросов SQL Server обычно выбирает наилучший план выполнения запроса, подсказки рекомендуется использовать только опытным разработчикам и администраторам баз данных в качестве последнего средства.
25 янв 17, 14:27    [20144603]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Eleanor
Member

Откуда:
Сообщений: 3411
Ролг Хупин,

Минус - можно однажды получить на проде ошибку
Query processor could not produce a query plan because of the hints defined in this query
25 янв 17, 14:29    [20144612]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Eleanor
Ролг Хупин,

Минус - можно однажды получить на проде ошибку
Query processor could not produce a query plan because of the hints defined in this query

на FORCESEEK???
25 янв 17, 14:31    [20144622]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Eleanor
Member

Откуда:
Сообщений: 3411
TaPaK,

В общем случае, если индекса не будет - получите. Хотя вряд ли кто-то ПК удалит.
Вроде самая безопасная подсказка OPTIMIZE FOR - даже не знаю, как сделать, чтобы план не смог построиться.
25 янв 17, 14:34    [20144642]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Eleanor
TaPaK,

В общем случае, если индекса не будет - получите. Хотя вряд ли кто-то ПК удалит.

весело. Отсутствие предиката и индекса вызывает ошибку.
25 янв 17, 14:46    [20144753]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
TaPaK
Ролг Хупин,

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

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


В общем - да, хотелось бы получить рекомендации опытных юзеров.
В моем случае, как описал, я не знаю почему оптимизатор выбрал scan, и из-за этого запрос выполнялся долго, вызывая блокировки и отстрел жертв.
Добавил хинт - все вылечилось. Потому и вопрос встал, может на что-то обратить внимание.
25 янв 17, 14:48    [20144774]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
invm
Member

Откуда: Москва
Сообщений: 9825
Ролг Хупин
Потому и вопрос встал, может на что-то обратить внимание.
На актуальность статистики.
25 янв 17, 14:52    [20144796]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
invm
Ролг Хупин
Потому и вопрос встал, может на что-то обратить внимание.
На актуальность статистики.


ага, обновить статистику и убрать этот хинт?
25 янв 17, 14:55    [20144833]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Ролг Хупин,

посмотрите план, там ясно станет почему scan, возможно у вас сохранён плохой план и вообще поставив FORCESEEK вы просто перекомпелировали
25 янв 17, 14:57    [20144848]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
TaPaK
Ролг Хупин,

посмотрите план, там ясно станет почему scan, возможно у вас сохранён плохой план и вообще поставив FORCESEEK вы просто перекомпелировали


После этого я снова убрал хинты из процедуры - снова долго выполняется.

Сделал апдейт статистики, проверил - без хинтов снова вылезли сканы
25 янв 17, 16:05    [20145383]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Ролг Хупин,

тестируете на одних и тех же условиях? если добавить RECOMPILE план тоже в scan?
25 янв 17, 16:09    [20145406]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
invm
Member

Откуда: Москва
Сообщений: 9825
Ролг Хупин,

Вы лучше планы актуальные покажите с хинтом и без.
25 янв 17, 16:15    [20145459]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
TaPaK
Ролг Хупин,

тестируете на одних и тех же условиях? если добавить RECOMPILE план тоже в scan?


условия - те же, сервер, база.
сделал exec sp_recompile 'proc'
пустил - снова скан
25 янв 17, 16:35    [20145609]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Ролг Хупин
TaPaK
Ролг Хупин,

тестируете на одних и тех же условиях? если добавить RECOMPILE план тоже в scan?


условия - те же, сервер, база.
сделал exec sp_recompile 'proc'
пустил - снова скан


exec sp_recompile 'proc' совсем не тоже что OPTION (RECOMPILE)
25 янв 17, 16:39    [20145629]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
TaPaK
Ролг Хупин
пропущено...


условия - те же, сервер, база.
сделал exec sp_recompile 'proc'
пустил - снова скан


exec sp_recompile 'proc' совсем не тоже что OPTION (RECOMPILE)


OPTION (RECOMPILE) имеется в виду у процедуры, чтобы каждый раз рекомпилировалась?
25 янв 17, 16:47    [20145661]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Eleanor
Member

Откуда:
Сообщений: 3411
Ролг Хупин,

Действительно, покажите оба плана. Вдруг у вас там всё равно estimated rows и actual rows сильно отличаются.
25 янв 17, 16:51    [20145679]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Ролг Хупин,

уффф давйте просто план

OPTION (RECOMPILE) хинт запроса
WITH RECOMPILE хинт процедуры
25 янв 17, 16:51    [20145682]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
Eleanor
Ролг Хупин,

Действительно, покажите оба плана. Вдруг у вас там всё равно estimated rows и actual rows сильно отличаются.


там развесистый запрос, попробую минимизировать и выложить

Но сейчас так: без forceseek, 4 сек работает, scan, estimated = 7405434, actual = 7406190,
forceseek, <1 сек работает, seek, estimated = 1 actual = 21
25 янв 17, 18:57    [20146234]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Ролг Хупин,

У вас forceseek заставляет использовать предикат индекса в первую очередь, в то время как обычный план накладывает остальные условия. Почему sql так решил из предоставленного не понять и сказать что это хорошо тоже
25 янв 17, 21:06    [20146685]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
o-o
Guest
Ролг Хупин
там развесистый запрос, попробую минимизировать и выложить

не надо минимизировать, надо зипить план.
прекрасно сжимается
25 янв 17, 22:03    [20146822]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Запрос уже приведите
25 янв 17, 23:07    [20147018]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Ролг Хупин
Eleanor
Ролг Хупин,

Действительно, покажите оба плана. Вдруг у вас там всё равно estimated rows и actual rows сильно отличаются.


там развесистый запрос, попробую минимизировать и выложить
Вы надеюсь не картинку собрались выкладывать? А то мы фотографиям лечить не умеем.
25 янв 17, 23:19    [20147036]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
Вот упрощенный скрипт, демонстрирующий мою ситуацию.
Там есть комментарий для forceseek, в таком варианте clustered index scan, если его убрать получаем второй план, в нем используется seek.


SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO
/*
DROP TABLE [dbo].[xv]
DROP TABLE [dbo].[x]
DROP TABLE [dbo].[n3]
*/

CREATE TABLE [dbo].[n3](
	[id] [uniqueidentifier] NOT NULL,
	[parent_id] [uniqueidentifier] NOT NULL,
 CONSTRAINT [PK_n3] PRIMARY KEY CLUSTERED 
(
	[id] ASC
)
)

GO

CREATE TABLE [dbo].[x](
	[obj_id] [uniqueidentifier] NOT NULL,
	[id] [int] IDENTITY(1,1) NOT NULL,
 CONSTRAINT [PK_x] PRIMARY KEY CLUSTERED 
(
	[id] ASC
))

GO

ALTER TABLE [dbo].[x]  WITH CHECK ADD  CONSTRAINT [FK_x_n3] FOREIGN KEY([obj_id])
REFERENCES [dbo].[n3] ([id])
ON DELETE CASCADE
GO

ALTER TABLE [dbo].[x] CHECK CONSTRAINT [FK_x_n3]
GO

CREATE TABLE [dbo].[xv](
	[id] [int] NOT NULL,
	[value] [sql_variant] NOT NULL,
 CONSTRAINT [PK_xv] PRIMARY KEY CLUSTERED 
(
	[id] ASC
))

GO

ALTER TABLE [dbo].[xv]  WITH CHECK ADD  CONSTRAINT [FK_xv_x] FOREIGN KEY([id])
REFERENCES [dbo].[x] ([id])
ON DELETE CASCADE
GO

ALTER TABLE [dbo].[xv] CHECK CONSTRAINT [FK_xv_x]
GO

INSERT INTO n3(id,parent_id)
select newid(), '975422E0-5630-4545-8CF7-062D7DF72B6B'
GO 10

INSERT INTO n3(id,parent_id)
select newid(), '805422E0-5630-4545-8CF7-062D7DF72B6B'
GO 5

INSERT INTO x([obj_id]) 
select id from n3 where parent_id='975422E0-5630-4545-8CF7-062D7DF72B6B';

insert into xv (id, value) 
select id, cast(RAND(1) as sql_variant) from x 

-- Demo query
  SELECT n3.id as node_id,x.id as id,
  (select xv.value from dbo.xv 
  --with(forceseek)  
  where xv.id=x.id
  ) as [value]
  FROM dbo.x
  INNER JOIN dbo.n3
  ON x.[obj_id]=n3.id
  AND n3.parent_id = '975422E0-5630-4545-8CF7-062D7DF72B6B'


/*
DROP TABLE [dbo].[xv]
DROP TABLE [dbo].[x]
DROP TABLE [dbo].[n3]
*/
26 янв 17, 19:53    [20150997]     Ответить | Цитировать Сообщить модератору
 Re: FORCESEEK: Это хорошо или плохо?  [new]
invm
Member

Откуда: Москва
Сообщений: 9825
Ролг Хупин
Вот упрощенный скрипт, демонстрирующий мою ситуацию.
Ничего он не демонстрирует.
Данных у вас по одной странице на таблицу. Поэтому бессмысленно делать поиск по индексу.
26 янв 17, 20:50    [20151122]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить