|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Есть две таблицы Детали и Тестирование. Нужно вывести все детали, не проходящие тестирование в определённом году. Есть 2 особенности: 1. Есть детали которые вообще не проходят тестирование, их надо выводить тоже; 2. Есть детали которые проходят тестирование по много раз, и таких много. Связь 1 : М. Написал вот такой запрос: select distinct name from Detales dt left join Testing ts on ts.ID_Detail = dt.ID where ts.DateBegin not like '%2015%' Но из-за второй особенности выборка получается неверная, выводятся детали которые были протестированы. Переписал вот так : select name from Detales dt where dt.ID <> (select distinct ID_Detale from Testing ts where ts.DateBegin like '%2015%') Работает, но такой запрос слишком громоздкий. Как можно написать его используя один селект? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 10:40 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
RonaldLRivest, Код: sql 1. 2. 3. 4.
При внешнем соединении таблицы все условия фильтрации по ней должны быть в кляузе ON. Если вы помещаете их в WHERE, ваш left join превращается в inner. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 10:51 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Ennor Tiegael Если вы помещаете их в WHERE, ваш left join превращается в inner. Главное, чтобы значения NULL сравнивались в WHERE только операторами IS NULL или IS NOT NULL ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 11:12 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Ennor Tiegael, Не работает так к сожалению. С таким where выводятся только детали, не участвующие в тестировании. Это правильно, но еще надо выводить остальные детали, которые участвуют в тестировании, но не в конкретном году. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 11:25 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 11:42 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
aleks222, С некоторыми поправками (not exists на exists) этот запрос работает правильно. Но он практически такой же, как тот, который хочу упростить) У него тоже несколько селектов) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 11:58 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
RonaldLRivest aleks222, С некоторыми поправками (not exists на exists) этот запрос работает правильно. Но он практически такой же, как тот, который хочу упростить) У него тоже несколько селектов) Качество запроса измеряется не числом селектов в нем, а временем исполнения. Вольно вам заниматься фигней. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:02 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
aleks222, если деталей тысяч сто, а тестирований по миллиону в году, Ваш запрос будет чистый треш. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:03 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
RonaldLRivest, пример данных дайте. Потому что запрос Ennor Tiegae верен только в случае верного предположения, в каком формате у Вас хранятся даты. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:04 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128, Даты храняться в varchar. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:09 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
aleks222, Это больше академическая задача чем практическая. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:10 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
aleks222 Качество запроса измеряется не числом селектов в нем, а временем исполнения. Во-первых, не временем исполнения, а временем загрузки CPU и IO. Обычно, лучше иметь запрос выполняющийся на 10-20% дольше на одном ядре, чем выполняющийся быстрее, но на 32-х ядрах. Во-вторых, конструкцию LIKE '%...' следет избегать всеми силами. Потому что, в лучшем случае, она подразумевает полное сканирование кластерного индекса, а в худшем - сканирование всей таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:10 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
RonaldLRivest, точнее. Приведите примеры хотя бы нескольких строк данных каждой таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:11 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Все, ответ нашел, проверил, работает https://ru.stackoverflow.com/questions/1229276/Связать-две-таблицы-joinом-при-связи-1М ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:12 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Спасибо всем. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:14 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
RonaldLRivest, это опять уход в Table Scan/Clustered Index Scan. Не стоит так делать. P.S. Нет вру. Если индекс по ID_Detail еще пройдет. Но при сравнении все равно лучше избегать функций со стороны присоединяемой таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:14 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128, Да, согласен. Но в данном случае этот пример больше академический чем практический, нужно именно локаничный и понятный, минимальный запрос. Спасибо вам. Если есть варианты, лишними не будут. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:19 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
RonaldLRivest еще надо выводить остальные детали, которые участвуют в тестировании, но не в конкретном году. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:20 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Ennor Tiegael, вот здесь результат можно посмотреть https://ru.stackoverflow.com/questions/1229276/Связать-две-таблицы-joinом-при-связи-1М ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:22 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Ennor Tiegael, судя по тому, как запрос по ссылке лихо преобразовал строку в дату, она там в ISO формате ) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:24 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Ennor Tiegael, Да, я неправильно вам ответил, where у вас правильный был. Дело в соединении было. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:26 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
RonaldLRivest, Вот и используйте запрос Ennor Tiegael. К нему у меня претензий по оптимальности нет. При правильных индексах, само собой. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:32 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
Ennor Tiegael, Извиняюсь. Сейчас проверил, ваш запрос верен, я сам его походу случайно в первый раз переделал. Сам виноват. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 12:36 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
RonaldLRivest, А, окей. Бывает. Удачи. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 13:32 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 aleks222, если деталей тысяч сто, а тестирований по миллиону в году, Ваш запрос будет чистый треш. Балоболить изволите? Дык балаболить - не мешки ворочать запросы писать. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.01.2021, 13:47 |
|
Связать две таблицы 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 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm, лично с Вас, $20 за ответ. Реквизиты пришлю в ответ на письмо. Ответ обещаю с примером, причем повторяемым. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 16:01 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128, Ну докажите сначала, что Вы в состоянии дать адекватный пример. А то деньги возьмете и с приветом... Хотя бы принцип его работы объясните. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 16:58 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm, Попробуйте сами ответить на вопросы: Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(1)? Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(0)? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 17:27 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(1)? Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(0)? Даже если Ваша таблица в обсуждаемом примере кластерная, физических чтений не будет больше, чем общее число страниц кластерного индекса. Потому что сервер не дурак и не будет поднимать с диска страницу, если она уже есть в BP. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 22:33 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
invm, Я же Вам выше стоимость моих ответов озвучил. Жду в e-mail ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 23:14 |
|
Связать две таблицы join'ом при связи 1:М.
|
|||
---|---|---|---|
#18+
ptr128 Я же Вам выше стоимость моих ответов озвучил. Жду в e-mail Так что имею все основания считать, что потрачу деньги впустую. Свои утверждения принято либо доказывать, либо ссылаться на авторитетные источники. Вы не сделали ни того, ни другого. Своим опусом 22261187 Вы ничего не доказали, а фразой ptr128 Во-вторых, видим, что параллельный план запроса в данном случае потребовал 2246 дополнительных обращений к кешу данных. То есть, при недостатке памяти дважды с диска могло читаться 0.6% страниц. Таким процентом я готов пренебречь. А было бы 6% - это уже стало бы поводом для размышлений в случае многопользовательской системы. К тому же, это вообще не ответ на обсуждаемый вопрос. В завершение, у меня для Вас, совершенно бесплатно, два подарка: 1. Для восполнения отсутствующих знаний - https://www.red-gate.com/simple-talk/sql/learn-sql-server/understanding-and-using-parallelism-in-sql-server/ и https://www.sqlservergeeks.com/lru-k-algorithm-quick-look/ 2. Скрипт, демонстрирующий физические чтения, который можете использовать для собственных экспериментов Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2021, 11:17 |
|
|
start [/forum/topic.php?all=1&fid=46&tid=1685210]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
168ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
79ms |
get tp. blocked users: |
2ms |
others: | 296ms |
total: | 593ms |
0 / 0 |