Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Почему такой зверский план выполнения?!!! / 19 сообщений из 19, страница 1 из 1
07.03.2019, 10:59
    #39783416
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Всем привет!

Вот такой запрос (вместо многоточий между фигурными скобками где-то килобайт в синтаксисе JSON):
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
MERGE FileMetaData.[File] AS TARGET
USING (VALUES
	( 111, '2019-03-07 08:21:50', N'{ ... }' ),
	( 222, '2019-03-07 08:21:50', N'{ ... }' ),
	......
	( 999, '2019-03-07 08:21:50', N'{ ... }' )
) AS SOURCE(
	Id, LastScanTime, MetaInfo
) ON 1=1
	AND TARGET.Id = SOURCE.Id
WHEN MATCHED THEN
	UPDATE SET
		MetaInfo     = SOURCE.MetaInfo,
		LastScanTime = SOURCE.LastScanTime;



Пораждает какой-то дикий execution plan (на картинке).
Почему так?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 11:08
    #39783418
Ivan Durak
Ivan Durak
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
нормальный план. засканить кусок кластерного индекса один раз. Это куда лучше чем сотню раз в нем по одной записи искать.
даже с учетом сортировки скаляров. Хотя может сортировка скаляров и тянет.... из-за килобайтов джейсона.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 11:11
    #39783421
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Yuri Abele,

Вас смущает диапазон поиска Id?

что в гистограмме FileMetaData.[File].PK?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 11:28
    #39783435
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
felix_ffYuri Abele,

Вас смущает диапазон поиска Id?

что в гистограмме FileMetaData.[File].PK?
В т.ч.. Зачем он так ищет?:
Код: sql
1.
ID >= ... AND ID <= ...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 11:32
    #39783439
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
И зачем ему при поиске по кластерному индексу, вытаскивать имеющиеся значаение поля MetaInfo?
Я же не сравниваю его ни с чем, просто перезаписываю
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 11:37
    #39783445
invm
invm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
План покажите в формате sqlplan.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 11:38
    #39783449
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Yuri Abele,

Код: sql
1.
2.
3.
WHEN MATCHED THEN
	UPDATE SET
		MetaInfo     = SOURCE.MetaInfo,



вы его переиспользуете в своей update, поэтому и тянет.

а по диапазону, необходимо посмотреть гистограмму.
да и вообще бы желательно весь план в формате .sqlplan а не скриншот.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 11:58
    #39783468
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Подсократил в плане количество строк из VALUES TABLE. В оригинале их 100.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 12:04
    #39783473
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Пораллельно с обновлением [MetaInfo] бежит еще процесс, который обновляет поле [HashSum] (см. ниже) - план выполнения идентичный предыдущему.
Оба эти запроса еще недавно выполнялись, приактически, мгновенно.
Теперь же, минимум минуту!

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
MERGE FileMetaData.[File] WITH (ROWLOCK) AS TARGET
USING (VALUES
	( 8098920, '2019-03-07 09:42:03', 0xDB5873057F26404AE9DF216EF7242D36F4916245C0EE888B181A207F0D911327 ),
	( 8098921, '2019-03-07 09:42:03', 0xBA90CEB46D7222EC7A091055827233F616B110466FEA86D9DAA1B0973F520F98 ),
	( 8098923, '2019-03-07 09:42:03', 0xFBBEAD9D492D31C4D13B4683E0B9FFF6A2EF843CD61CE3EB865B35FF54DEEEA9 ),
	.....
) AS SOURCE(
	Id, LastScanTime, HashSum
) ON 1=1
	AND TARGET.Id = SOURCE.Id
WHEN MATCHED THEN
	UPDATE SET
		HashSum      = SOURCE.HashSum,
		LastScanTime = SOURCE.LastScanTime;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 12:05
    #39783475
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Ой, вот этого в запросе нет. Скопировал нечайно текст из экспериментов:
Код: sql
1.
... WITH (ROWLOCK) ...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 12:26
    #39783483
Ivan Durak
Ivan Durak
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
реальный план покеж
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 12:29
    #39783487
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Yuri Abele,

Так а в чем собственно проблема?

Вы приложили предполагаемый план, а не фактический.

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

сделайте
Код: sql
1.
 dbcc show_statistics ([VEA].[FileMetaData].[File], [FileMetaData.File.PK.Id]) with histogram



при этом могу предположить: если у вас два параллельных merge, один временно блокирует другого
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 12:37
    #39783495
invm
invm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Yuri AbeleВ т.ч.. Зачем он так ищет?:
Код: sql
1.
ID >= ... AND ID <= ...

Чтоб не делать лишнюю работу.
При компиляции запроса из ваших values определяются минимальное и максимальное значения id и далее используются для сканирования диапазона кластерного индекса вместо его полного сканирования.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 12:50
    #39783501
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
felix_ffсделайте
Код: sql
1.
dbcc show_statistics ('FileMetaData.[File]', 'FileMetaData.File.PK.Id') with histogram



Выдает таблицу в 195 строк. Как ее показать? Скриншотом?

P.S. А смысл? Это же поле CLUSTERED PRIMARY KEY - там по определению каждое значение только один раз.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 12:55
    #39783506
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
В приложении "живой" план выполнения. Я взял только для HashSum, он (в байтах) покомпактнее.
И я для строк VALUES TABLE уже из плана вырезал большую часть, оставил только 5 Rows.
Иначе файл слишком здоровый
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 14:08
    #39783556
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Yuri Abele,

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

в этом случае это границы [8098917; 8099044]
в таком диапазоне поиск по индексу выдаст вам 128 строк, но поскольку значений в (using values ) у вас 100 ему надо убрать лишние 28 строк, на что и делается constant scan + sort для возможности применения merge join двух наборов.

8098917 - значение у вас присутствует в списке значений, 8099044 - я не увидел или вы его вырезали или оно подогнано оптимизатором из гистограммы статистики.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 14:34
    #39783572
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
felix_ff8098917 - значение у вас присутствует в списке значений, 8099044 - я не увидел или вы его вырезали или оно подогнано оптимизатором из гистограммы статистики.
Да, я вырезал. Там пакетами по 100 строк бомбит.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 15:26
    #39783602
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Большущее спасибо за помощь по анализу!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
08.03.2019, 09:59
    #39783829
Yuri Abele
Yuri Abele
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Почему такой зверский план выполнения?!!!
Почистил через JSON_MODIFY ненужные элементы в нагенеренных MetaInfo,
Потом прогнал INDEX REORGONIZE ALL по этой таблице.
Итог - размер таблицы в байтах уменьшился порядка в 50 раз.
Тут уже можно дышать :-)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Почему такой зверский план выполнения?!!! / 19 сообщений из 19, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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