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

Откуда:
Сообщений: 5951
Если я правильно помню, кто-то где-то рассказывал, что при Unknown предполагается равномерное распределение данных по страницам при том, что объем полезной информации занимает 30%.
30 ноя 18, 11:28    [21749687]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2107
TaPaK
Mind
пропущено...
Заглулил, молодец! То есть настолько не уверен в своих знаниях или умениях объяснять что пришлось гуглить? И то что я сказал абсолютно тоже самое но своими словами тоже сложно было понять?

где там про "средние"
Ты понимаешь хоть то что там написано или просто скопировал? У тебя в статистических данных 200 строк со значениями, как ты будешь их использовать? Все сразу?
Вот у тебя известно что в таблице есть:
1 значение 100
5 значений 200
20 значений 300
WHERE id = @id OPTIMIZE FOR UNKNOWN сколько строк вернет согласно оценке оптимизатора?
30 ноя 18, 11:34    [21749697]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 5671
Mind
TaPaK
пропущено...

где там про "средние"
Ты понимаешь хоть то что там написано или просто скопировал? У тебя в статистических данных 200 строк со значениями, как ты будешь их использовать? Все сразу?
Вот у тебя известно что в таблице есть:
1 значение 100
5 значений 200
20 значений 300
WHERE id = @id OPTIMIZE FOR UNKNOWN сколько строк вернет согласно оценке оптимизатора?

согласно этому хинту актуальный план будет всегда учитывать значение статистики по переданным переменным, а на столбить ваши 20 строк или сколько вы там себе нафаназировали.
Recompile же будет принудительно перекомпилировать запрос с проброшенным значением.
30 ноя 18, 11:38    [21749706]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
PizzaPizza
Member

Откуда:
Сообщений: 146
gepard1980
PizzaPizza, возвращаются 9 числовых полей без блобов. Думаю это не сильно влияет на перфоманс. Есть таблица с 70 полями. Вот из нее уже select * накладно делать.


Тривиальный план + 100% загружающий io + ошибки Table errorы = делайте чекдиск и разбирайтесь с дисками, надеюсь с бекапами у вас все хорошо
30 ноя 18, 19:04    [21750663]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2107
Наконец то. А столько пафоса было: "как разберешься - приходи". А в чем разница между "по переданным переменным" и "с проброшенным значением"?
TaPaK
согласно этому хинту актуальный план будет всегда учитывать значение статистики по переданным переменным, а на столбить ваши 20 строк или сколько вы там себе нафаназировали.
Recompile же будет принудительно перекомпилировать запрос с проброшенным значением.
Так все таки, переданные переменные будут учитываться или нет? Потому что в твоей цитате из документации сказано прямо противоположное:
TaPaK
Instructs the query optimizer to use statistical data instead of the initial values for all local variables
Вообще конечно тот кто писал документацию мягко говоря очень далек от SQL Server-а, потому что написал он полную чушь.

Во-первых, о каких local variables идет речь если учитывать что для локальных переменных никакого parameter sniffing нет и быть не может, сервер по-дефолту не знает значения локальных переменных и это опция оптимизатора вообще тут не имеет никакого эффекта.
Во-вторых "use statistical data" - то есть если не указать FOR UNKNOWN то оптимизатор не будет использовать "statistical data"? Что за бред вообще.
Мне потому и смешно что ты процитировал это запутанное и по сути безсмысленное определение и не смог даже нормально перевести его.

OPTIMIZE FOR UNKNOWN - или по сути оптимизация под неизвестное значение так и называется, потому что не важно видит оптимизатор значения параметров/переменных или нет, все равно мы ему говорим оптимизируй запрос так как будто для тебя эти значения неизвестны (UNKNOWN). Ну или еще более упрощенно - оптимизируй запрос так как если бы все параметры были переменными, для которых как мы знаем "просмотр значений" не работает по умолчанию. Именно поэтому, до существования такой опции можно было переназначить параметры локальным переменным и использовать уже их в запросе, и это приводило по сути к тому же эффекту.


Ну а теперь самое интересное, вопрос на который ты не смог ответить, о том как сервер использует статистику для оценочного определения количества строк. Неужели даже интересно не было? Тест накидать за 2 минуты и самому проверить? Для саморазвития так сказать? Нет, зачем же. Гениям это не надо.

+ Скрипт
SET NOCOUNT ON
CREATE TABLE dbo.T(id int)
INSERT T(id) VALUES(100)
GO 1
INSERT T(id) VALUES(200)
GO 5
INSERT T(id) VALUES(300)
GO 20

SET SHOWPLAN_ALL ON
GO
DECLARE @id int = 100
SELECT * FROM dbo.T WHERE id = @id OPTION(OPTIMIZE FOR UNKNOWN)
GO
SET SHOWPLAN_ALL OFF
GO
DROP TABLE T

Результат:
StmtText EstimateRows
DECLARE @id int = 100 NULL
SELECT * FROM dbo.T WHERE id = @id OPTION(OPTIMIZE FOR UNKNOWN) 8.666667
|--Table Scan(OBJECT:([master].[dbo].[T]) WHERE:([master].[dbo].[T].[id]=[@id])) 8.666667

Откуда же берутся эти 8.67? Из статистики:

RANGE_HI_KEY RANGE_ROWS EQ_ROWS DISTINCT_RANGE_ROWS AVG_RANGE_ROWS
100 0 1 0 1
200 0 5 0 1
300 0 20 0 1

(1+5+20)/3=8.66667
TaPaK
где там про "средние"
Это называется среднее арифметическое. Урок «Среднее арифметическое чисел», 5 класс


P.S. Не забудь запатентовать что опция OPTIMIZE FOR UNKNOWN ускоряет работу дисков в 5 раз.
30 ноя 18, 23:20    [21750832]     Ответить | Цитировать Сообщить модератору
 Re: Долгое выполнение хранимых процедур  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 2257
invm
Лог транзакций не может расти, тем более постоянно, если в базу ничего не пишется. Вам об этом уже писали..


delete?
1 дек 18, 09:48    [21750912]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6]      все
Все форумы / Microsoft SQL Server Ответить