ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Почему такой зверский план выполнения?!!!
19 сообщений из 19, страница 1 из 1
Почему такой зверский план выполнения?!!!
    #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, 10:59
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783418
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
нормальный план. засканить кусок кластерного индекса один раз. Это куда лучше чем сотню раз в нем по одной записи искать.
даже с учетом сортировки скаляров. Хотя может сортировка скаляров и тянет.... из-за килобайтов джейсона.
...
Рейтинг: 0 / 0
07.03.2019, 11:08
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783421
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
felix_ff
Участник
Yuri Abele,

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

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

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

что в гистограмме FileMetaData.[File].PK?
В т.ч.. Зачем он так ищет?:
Код: sql
1.
ID >= ... AND ID <= ...
...
Рейтинг: 0 / 0
07.03.2019, 11:28
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783439
Фотография Yuri Abele
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yuri Abele
Участник
И зачем ему при поиске по кластерному индексу, вытаскивать имеющиеся значаение поля MetaInfo?
Я же не сравниваю его ни с чем, просто перезаписываю
...
Рейтинг: 0 / 0
07.03.2019, 11:32
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783445
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
invm
Участник
План покажите в формате sqlplan.
...
Рейтинг: 0 / 0
07.03.2019, 11:37
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #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:38
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783468
Фотография Yuri Abele
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yuri Abele
Участник
Подсократил в плане количество строк из VALUES TABLE. В оригинале их 100.
...
Рейтинг: 0 / 0
07.03.2019, 11:58
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #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:04
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783475
Фотография Yuri Abele
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yuri Abele
Участник
Ой, вот этого в запросе нет. Скопировал нечайно текст из экспериментов:
Код: sql
1.
... WITH (ROWLOCK) ...
...
Рейтинг: 0 / 0
07.03.2019, 12:05
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783483
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
реальный план покеж
...
Рейтинг: 0 / 0
07.03.2019, 12:26
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #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:29
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783495
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
invm
Участник
Yuri AbeleВ т.ч.. Зачем он так ищет?:
Код: sql
1.
ID >= ... AND ID <= ...

Чтоб не делать лишнюю работу.
При компиляции запроса из ваших values определяются минимальное и максимальное значения id и далее используются для сканирования диапазона кластерного индекса вместо его полного сканирования.
...
Рейтинг: 0 / 0
07.03.2019, 12:37
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #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:50
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783506
Фотография Yuri Abele
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yuri Abele
Участник
В приложении "живой" план выполнения. Я взял только для HashSum, он (в байтах) покомпактнее.
И я для строк VALUES TABLE уже из плана вырезал большую часть, оставил только 5 Rows.
Иначе файл слишком здоровый
...
Рейтинг: 0 / 0
07.03.2019, 12:55
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #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:08
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783572
Фотография Yuri Abele
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yuri Abele
Участник
felix_ff8098917 - значение у вас присутствует в списке значений, 8099044 - я не увидел или вы его вырезали или оно подогнано оптимизатором из гистограммы статистики.
Да, я вырезал. Там пакетами по 100 строк бомбит.
...
Рейтинг: 0 / 0
07.03.2019, 14:34
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783602
Фотография Yuri Abele
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yuri Abele
Участник
Большущее спасибо за помощь по анализу!
...
Рейтинг: 0 / 0
07.03.2019, 15:26
| Ответить | Цитировать | Написать  
Почему такой зверский план выполнения?!!!
    #39783829
Фотография Yuri Abele
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yuri Abele
Участник
Почистил через JSON_MODIFY ненужные элементы в нагенеренных MetaInfo,
Потом прогнал INDEX REORGONIZE ALL по этой таблице.
Итог - размер таблицы в байтах уменьшился порядка в 50 раз.
Тут уже можно дышать :-)
...
Рейтинг: 0 / 0
08.03.2019, 09:59
| Ответить | Цитировать | Написать  
19 сообщений из 19, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Почему такой зверский план выполнения?!!!
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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