|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Во-первых, не временем исполнения, а временем загрузки CPU и IO ptr128 Если индекс по ID_Detail еще пройдет ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 14:11 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm При одинаковых результатах запросов, чем меньше IO, тем оптимальнее? Однозначного ответа нет. Можно такой запрос написать, что IO будет мал, а CPU сожрет сотни секунд. А можно с IO в два раза большим, но выполняющийся за секунду. Например, попробуйте создать native compiled процедуру в тот момент, когда используемые ей таблицы пустые. Если не рекомпилировать ее или принудительно запрос в ней, после заполнения таблиц обнаружите много приятных неожиданностей. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 15:11 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Однозначного ответа нет. ptr128 не временем исполнения, а временем загрузки CPU и IO. А критерии оптимальности для каждого свои. Для конечного пользователя - это время выполнения и ему плевать, что запрос для быстрого выполнения сожрал все ресурсы. Для ТС - это вообще "громоздкость". И плевать ему на хранение дат как строк, саргабельность предикатов и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 15:54 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm зачем тогда писать Затем, что SQL сервер, в общем случае, используется в многопользовательском режиме. И только в случае явного указания ТС об использовании сервера в монопольном режиме, подход оценки только времени выполнения запроса оправдан. invm Для конечного пользователя - это время выполнения и ему плевать, что запрос для быстрого выполнения сожрал все ресурсы. Сами себе противоречите. Пользователю еще можно простить отсутствие знаний по архитектуре SQL Server. А Вам? Если Вася своим запросом "сожрал все ресурсы", то запрос Пети будет ждать, пока закончится запрос Васи, например, ожидая освобождения немерянного объема запрошенного планировщиком памяти. И конечный пользователь Петя будет возмущаться и будет при этом прав. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 16:07 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 invm зачем тогда писать Затем, что SQL сервер, в общем случае, используется в многопользовательском режиме. И только в случае явного указания ТС об использовании сервера в монопольном режиме, подход оценки только времени выполнения запроса оправдан. invm Для конечного пользователя - это время выполнения и ему плевать, что запрос для быстрого выполнения сожрал все ресурсы. Сами себе противоречите. Пользователю еще можно простить отсутствие знаний по архитектуре SQL Server. А Вам? Если Вася своим запросом "сожрал все ресурсы", то запрос Пети будет ждать, пока закончится запрос Васи, например, ожидая освобождения немерянного объема запрошенного планировщиком памяти. И конечный пользователь Петя будет возмущаться и будет при этом прав. Больные фантазии. Чем быстрее запрос выполнится - тем быстрее петя получит свое щастье. ЗЫ. Можно бесконечно жевать сопли ниочем. Но это контрпродуктивно. Чем меньше требуется времени для выполнения запроса - тем меньше ресурсов жрет этот запрос. Ибо пожирание ресурсов ТОЖЕ требует времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 16:23 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
aleks222 Чем меньше требуется времени для выполнения запроса - тем меньше ресурсов жрет этот запрос. Ибо пожирание ресурсов ТОЖЕ требует времени. Ядра CPU это ресурс? Если нет, можно считать Вас троллем и расслабиться. Если да, то из Вашего утверждение вытекает, что запрос с MAXDOP 0, по сравнению с MAXDOP 1, потребует времени на "пожираение ресурсов" (дополнительных ядер), а значит будет выполняться дольше? Память это ресурс? Опять, если нет, можно считать Вас троллем и расслабиться. Если да, то из Вашего утверждения вытекает, что запрос планировщиком 90% памяти сервера выполняется дольше, чем запрос 10% памяти сервера? Фактическое потребление памяти будем считать в обеих случаях одинаковым. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 17:18 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Затем, что SQL сервер, в общем случае, используется в многопользовательском режиме. Для простоты исключим параллелизм и будем считать, что памяти у нас неограниченно. Тогда затраты CPU на выполнение одного и того же запроса на одних и тех же данных при неизменном плане не зависит от количества активных пользователей. Разница между Elapsed time и CPU time - есть суммарное время ожидания различных ресурсов, будь то IO, блокировки, передача результатов клиенту и т.п. И ваши попытки приплести количество IO в качестве критерия бессмысленны. Если проще - затраты на IO (без ожиданий) уже включены в CPU time. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 17:34 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
"Не путайтесь в показаниях." (с) invm исключим параллелизм Ваше ЧСВ, вроде бы, было задето именно этим сообщением: ptr128 Во-первых, не временем исполнения, а временем загрузки CPU и IO. Обычно, лучше иметь запрос выполняющийся на 10-20% дольше на одном ядре, чем выполняющийся быстрее, но на 32-х ядрах. Не правда ли? К слову, параллелятся далеко не только ядра, но и запросы ввода-вывода (IO). Что-нибудь об СХД или хотя бы RAID слышали? Для Вас, наверное, будет открытием, но на то, чтобы получить с СХД мегабайт данных десятью запросами из десяти потоков может уйти в несколько раз меньше времени, чем при получении того же мегабайта, но одним запросом или десятью последовательными запросами из одного потока. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 17:44 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128, Вы написали фигню. И было объяснено почему именно. Если не доходит - перечитывайте мой ответ до понимания. Если понимание не приходит, подумайте - почему в статистике выполнения есть CPU time и Elapsed time, но нет IO time? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 18:17 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
"Вы написали фигню. И было объяснено почему именно. Если не доходит - перечитывайте мой ответ до понимания." (С) invm нет IO time? Потому что SQL сервер его не знает. Эту статистику даже система не знает, хотя и обладает возможностями ее узнать в частных случаях. Только СХД. Косвенно эту статистику можно оценить через системные счетчики производительности. Но если СХД обслуживает несколько серверов эта информация Вам даст мало полезного. Попробуйте все же погуглить и дать ответ на вопрос: Различается ли нагрузка на СХД при чтении одного мегабайта одним запросом ввода-вывода от нагрузки при чтении этого же мегабайта десятью запросами ввода-вывода? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 19:26 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Потому что SQL сервер его не знает. Осознайте простую вещь: единственный объективный критерий, по которому можно сравнивать производительность разных запросов, решающих одну и ту же задачу - это CPU time. Все остальное - случайные значения на момент выполнения. А если уж так хочется грубо оценить потенциальное влияние IO - выполните запрос в тех же тепличных условиях, но предварительно очистите BP. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 19:52 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm Если не знает, то как вы собрались это учитывать? Элементарно, Ватсон. Косвенным путем глядя на scan count, logical reads и physical reads. Попробую пояснить на примере. Есть табличка: Код: plaintext 1. 2.
Код: sql 1.
Код: plaintext 1. 2.
Код: sql 1.
Код: plaintext 1. 2.
Во-первых, сразу видим во сколько потоков выполнялся запрос (33-1=32). Во-вторых, видим, что параллельный план запроса в данном случае потребовал 2246 дополнительных обращений к кешу данных. То есть, при недостатке памяти дважды с диска могло читаться 0.6% страниц. Таким процентом я готов пренебречь. А было бы 6% - это уже стало бы поводом для размышлений в случае многопользовательской системы. invm Все остальное - случайные значения на момент выполнения. Данный пример заодно показывает, насколько Вы заблуждаетесь. После того, как вся таблица оказалась в кеше, все значения статистик ввода-вывода стабилизировались. То есть, они совсем не "случайные". Нужно просто уметь их правильно интерпретировать ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 20:26 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Элементарно, Ватсон. Косвенным путем глядя на scan count, logical reads и physical reads. Попробую пояснить на примере. IO есть физическое и логическое. Затраты времени на логическое регистрируется в CPU time, потому что (какая неожиданность) логическим занимается CPU. А на физическое - в ожиданиях PAGEIOLATCH*. Потому что поток ждет, когда завершатся инициированные им физические IO. Суммарно эти ожидания дадут время, затраченное на физические чтения и запись. Именно поэтому нет отдельной статистики IO time. Именно поэтому количество IO бестолку учитывать при сравнении производительности разных запросов, ибо оно уже учтено в CPU time. А ожидания к сравнению производительности вообще никак не относятся. Учите матчасть. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 21:29 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
"Вы просто физику процесса не понимаете." (с) invm Суммарно эти ожидания дадут время, затраченное на физические чтения и запись. Они дадут погоду на Марсе, так как в общем случае, мы не знаем, что уже в кеше, а чего там нет. В том то и дело, что для того, чтобы оценить нагрузку на СХД нам нужно проанализировать, количество страниц которые нужны запросу с одной стороны, и то, как часто наш сервер ходит на диск по sys.dm_io_virtual_file_stats. На практике, мне еще приходилось порой гонять с завидной регулярностью fio, чтобы можно было аргументированно разбираться с администраторами СХД по поводу обещанных и фактических IOPS. Впрочем мы начинали с того, как различается нагрузка на СХД при MAXDOP 0 и MAXDOP 1. И это я уже наглядно показал. Если все таблицы, используемые в запросе не могут поместиться в кеше - различается, так как читается разное количество страниц. А сколько реально прочиталось в процессе эксплуатации - смотрим уже в sys.dm_exec_query_stats и делаем выводы об этих запросах. В DWH параллельное выполнение запросов - хорошо. В высоконагруженной многопользовательской системе - не факт. Потому что может быть важно не столько то, сколько ждет результата запроса конкретный Вася. А сколько в среднем времени ожидают выполнения своих запросов все пользователи включая тех, кто ждет завершения Васиного запроса. "Учите матчасть." (С) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 22:44 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Они дадут погоду на Марсе, так как в общем случае, мы не знаем, что уже в кеше, а чего там нет. 2. И еще раз - учите матчасть. Дальнейшая дискуссия не имеет смысла, пока не осознаете разницу между анализом быстродействия одного запроса и сравнением быстродействия разных запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2021, 10:14 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128, гаданием на SQL метриках Вы не получите предсказание нагрузки СХД. Для получения ясной картины составьте нагрузочные сценарии, и по выполнению этих сценариев замеряйте нагрузку СХД. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 14:41 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Владислав Колосов, и даже нагрузочным сценарием не получу, если СХД обслуживает несколько серверов. Но сравнивая метрики двух запросов смогу оценить вероятность того, что один из запросов создаст больше нагрузку на СХД, чем другой. С точки зрения оптимизации запросов, это может быть полезным. Не более того. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 16:20 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Но сравнивая метрики двух запросов смогу оценить вероятность того, что один из запросов создаст больше нагрузку на СХД, чем другой. И по какой методике собрались определять эти вероятности? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 10:19 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm, Может хватит клоунады? Об общем времени IO спич вели исключительно Вы, тогда как я изначально вел речь только об оценке нагрузки на СХД при помощи статистик IO, что Вы считали и считаете бессмысленным. P.S. Мы же вроде бы договорились о прекращении дискуссий о размере пиписек как здесь, так и в будущем? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 10:33 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Об общем времени IO спич вели исключительно Вы, тогда как я изначально вел речь только об оценке нагрузки на СХД при помощи статистик IO ptr128 Во-первых, не временем исполнения, а временем загрузки CPU и IO. ptr128 Вы считали и считаете бессмысленным. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 11:14 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm ptr128 Во-первых, не временем исполнения, а временем загрузки CPU и IO. А где тут время IO? Или если я скажу, что схожу за хлебом в зависимости "от времени в пути и настроения", Вы решите, что я говорю об измерении настроения временем? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 11:26 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm Ну так продемонстрируйте смысл и методику его определния. Именно при сравнении быстродействия двух запросов. 22261187 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 11:30 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 А где тут время IO? ptr128 Итого, ответа на ptr128 Но сравнивая метрики двух запросов смогу оценить вероятность того, что один из запросов создаст больше нагрузку на СХД, чем другой. Только не нужно писать, что на самом деле тут идет речь о сравнении сериального и параллельного запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 13:15 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm, ответы все был даны выше. Дополнительные консультации за отдельную плату. До свидания. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 13:31 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 ответы все был даны выше. Дополнительные консультации за отдельную плату. До свидания. Итак, ответов на поставленные вопросы как не было, так и нет. Есть только много гонора... Попытка втюхать 22261187 как ответ и нечто полезное и высокомудрое - несостоятельна. Ибо на заданный вопрос не отвечает и Вашу всезнающую голову так и не посетил банальный вопрос - каким образом параллельное полное сканирование таблицы может дать, при прочих равных, большее количество физических чтений, чем такое же сериальное? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 14:59 |
|
|
start [/forum/topic.php?fid=46&msg=40035766&tid=1685210]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 144ms |
0 / 0 |