powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Связать две таблицы join'ом при связи 1:М.
56 сообщений из 56, показаны все 3 страниц
Связать две таблицы join'ом при связи 1:М.
    #40034559
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть две таблицы Детали и Тестирование.
Нужно вывести все детали, не проходящие тестирование в определённом году. Есть 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%')
Работает, но такой запрос слишком громоздкий. Как можно написать его используя один селект?
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034560
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RonaldLRivest,

Код: sql
1.
2.
3.
4.
select d.*
from dbo.Details d
  left join dbo.Testing t on t.ID_Detail = d.ID and t.DateBegin between '20150101' and '20151231'
where t.ID_Detail is null;

При внешнем соединении таблицы все условия фильтрации по ней должны быть в кляузе ON. Если вы помещаете их в WHERE, ваш left join превращается в inner.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034561
iap
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ennor Tiegael
Если вы помещаете их в WHERE, ваш left join превращается в inner.
Сами себе противоречите
Главное, чтобы значения NULL сравнивались в WHERE только операторами IS NULL или IS NOT NULL
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034564
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ennor Tiegael,

Не работает так к сожалению. С таким where выводятся только детали, не участвующие в тестировании. Это правильно, но еще надо выводить остальные детали, которые участвуют в тестировании, но не в конкретном году.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034565
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
2.
3.
with dt as ( select * from Detales )
   , ts as ( select * from Testing where DateBegin like '%2015%')
   select * from dt where not exists( select * from ts where dt.id <> ts.ID_Detale )
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034567
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
aleks222,

С некоторыми поправками (not exists на exists) этот запрос работает правильно. Но он практически такой же, как тот, который хочу упростить) У него тоже несколько селектов)
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034569
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RonaldLRivest
aleks222,

С некоторыми поправками (not exists на exists) этот запрос работает правильно. Но он практически такой же, как тот, который хочу упростить) У него тоже несколько селектов)

Качество запроса измеряется не числом селектов в нем, а временем исполнения.
Вольно вам заниматься фигней.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034570
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks222,

если деталей тысяч сто, а тестирований по миллиону в году, Ваш запрос будет чистый треш.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034571
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RonaldLRivest,

пример данных дайте. Потому что запрос Ennor Tiegae верен только в случае верного предположения, в каком формате у Вас хранятся даты.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034573
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ptr128,
Даты храняться в varchar.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034574
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
aleks222,

Это больше академическая задача чем практическая.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034575
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks222
Качество запроса измеряется не числом селектов в нем, а временем исполнения.

Во-первых, не временем исполнения, а временем загрузки CPU и IO. Обычно, лучше иметь запрос выполняющийся на 10-20% дольше на одном ядре, чем выполняющийся быстрее, но на 32-х ядрах.
Во-вторых, конструкцию LIKE '%...' следет избегать всеми силами. Потому что, в лучшем случае, она подразумевает полное сканирование кластерного индекса, а в худшем - сканирование всей таблицы.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034576
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RonaldLRivest,

точнее. Приведите примеры хотя бы нескольких строк данных каждой таблицы.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034577
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034578
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо всем.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034579
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RonaldLRivest,

это опять уход в Table Scan/Clustered Index Scan. Не стоит так делать.

P.S. Нет вру. Если индекс по ID_Detail еще пройдет. Но при сравнении все равно лучше избегать функций со стороны присоединяемой таблицы.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034580
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ptr128,

Да, согласен. Но в данном случае этот пример больше академический чем практический, нужно именно локаничный и понятный, минимальный запрос. Спасибо вам. Если есть варианты, лишними не будут.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034581
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RonaldLRivest
еще надо выводить остальные детали, которые участвуют в тестировании, но не в конкретном году.
Ни хрена не понял. Давайте пример данных и желаемый результат, предпочтительно в SQL-виде.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034583
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ennor Tiegael,

вот здесь результат можно посмотреть https://ru.stackoverflow.com/questions/1229276/Связать-две-таблицы-joinом-при-связи-1М
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034584
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ennor Tiegael,

судя по тому, как запрос по ссылке лихо преобразовал строку в дату, она там в ISO формате )
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034585
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ennor Tiegael,

Да, я неправильно вам ответил, where у вас правильный был. Дело в соединении было.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034588
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RonaldLRivest,

Вот и используйте запрос Ennor Tiegael. К нему у меня претензий по оптимальности нет. При правильных индексах, само собой.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034589
RonaldLRivest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ennor Tiegael,

Извиняюсь. Сейчас проверил, ваш запрос верен, я сам его походу случайно в первый раз переделал. Сам виноват.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034614
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RonaldLRivest,

А, окей. Бывает. Удачи.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034623
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
aleks222,

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


Балоболить изволите?
Дык балаболить - не мешки ворочать запросы писать.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034632
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
Во-первых, не временем исполнения, а временем загрузки CPU и IO
При одинаковых результатах запросов, чем меньше IO, тем оптимальнее?
ptr128
Если индекс по ID_Detail еще пройдет
Ага. Мимо индекса.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034645
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm
При одинаковых результатах запросов, чем меньше IO, тем оптимальнее?

Однозначного ответа нет. Можно такой запрос написать, что IO будет мал, а CPU сожрет сотни секунд. А можно с IO в два раза большим, но выполняющийся за секунду.

Например, попробуйте создать native compiled процедуру в тот момент, когда используемые ей таблицы пустые. Если не рекомпилировать ее или принудительно запрос в ней, после заполнения таблиц обнаружите много приятных неожиданностей.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034667
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
Однозначного ответа нет.
Ну если нет, то зачем тогда писать
ptr128
не временем исполнения, а временем загрузки CPU и IO.
?

А критерии оптимальности для каждого свои.
Для конечного пользователя - это время выполнения и ему плевать, что запрос для быстрого выполнения сожрал все ресурсы.
Для ТС - это вообще "громоздкость". И плевать ему на хранение дат как строк, саргабельность предикатов и т.п.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034670
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm
зачем тогда писать

Затем, что SQL сервер, в общем случае, используется в многопользовательском режиме. И только в случае явного указания ТС об использовании сервера в монопольном режиме, подход оценки только времени выполнения запроса оправдан.

invm
Для конечного пользователя - это время выполнения и ему плевать, что запрос для быстрого выполнения сожрал все ресурсы.

Сами себе противоречите. Пользователю еще можно простить отсутствие знаний по архитектуре SQL Server. А Вам? Если Вася своим запросом "сожрал все ресурсы", то запрос Пети будет ждать, пока закончится запрос Васи, например, ожидая освобождения немерянного объема запрошенного планировщиком памяти. И конечный пользователь Петя будет возмущаться и будет при этом прав.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034674
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
invm
зачем тогда писать

Затем, что SQL сервер, в общем случае, используется в многопользовательском режиме. И только в случае явного указания ТС об использовании сервера в монопольном режиме, подход оценки только времени выполнения запроса оправдан.

invm
Для конечного пользователя - это время выполнения и ему плевать, что запрос для быстрого выполнения сожрал все ресурсы.

Сами себе противоречите. Пользователю еще можно простить отсутствие знаний по архитектуре SQL Server. А Вам? Если Вася своим запросом "сожрал все ресурсы", то запрос Пети будет ждать, пока закончится запрос Васи, например, ожидая освобождения немерянного объема запрошенного планировщиком памяти. И конечный пользователь Петя будет возмущаться и будет при этом прав.

Больные фантазии.
Чем быстрее запрос выполнится - тем быстрее петя получит свое щастье.

ЗЫ. Можно бесконечно жевать сопли ниочем.
Но это контрпродуктивно.
Чем меньше требуется времени для выполнения запроса - тем меньше ресурсов жрет этот запрос.
Ибо пожирание ресурсов ТОЖЕ требует времени.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034691
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks222
Чем меньше требуется времени для выполнения запроса - тем меньше ресурсов жрет этот запрос.
Ибо пожирание ресурсов ТОЖЕ требует времени.


Ядра CPU это ресурс? Если нет, можно считать Вас троллем и расслабиться.
Если да, то из Вашего утверждение вытекает, что запрос с MAXDOP 0, по сравнению с MAXDOP 1, потребует времени на "пожираение ресурсов" (дополнительных ядер), а значит будет выполняться дольше?

Память это ресурс? Опять, если нет, можно считать Вас троллем и расслабиться.
Если да, то из Вашего утверждения вытекает, что запрос планировщиком 90% памяти сервера выполняется дольше, чем запрос 10% памяти сервера? Фактическое потребление памяти будем считать в обеих случаях одинаковым.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034693
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
Затем, что SQL сервер, в общем случае, используется в многопользовательском режиме.
Не путайтесь в показаниях.

Для простоты исключим параллелизм и будем считать, что памяти у нас неограниченно.
Тогда затраты CPU на выполнение одного и того же запроса на одних и тех же данных при неизменном плане не зависит от количества активных пользователей.
Разница между Elapsed time и CPU time - есть суммарное время ожидания различных ресурсов, будь то IO, блокировки, передача результатов клиенту и т.п.
И ваши попытки приплести количество IO в качестве критерия бессмысленны.

Если проще - затраты на IO (без ожиданий) уже включены в CPU time.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034696
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Не путайтесь в показаниях." (с)
invm

исключим параллелизм


Ваше ЧСВ, вроде бы, было задето именно этим сообщением:
ptr128
Во-первых, не временем исполнения, а временем загрузки CPU и IO. Обычно, лучше иметь запрос выполняющийся на 10-20% дольше на одном ядре, чем выполняющийся быстрее, но на 32-х ядрах.

Не правда ли?

К слову, параллелятся далеко не только ядра, но и запросы ввода-вывода (IO). Что-нибудь об СХД или хотя бы RAID слышали?

Для Вас, наверное, будет открытием, но на то, чтобы получить с СХД мегабайт данных десятью запросами из десяти потоков может уйти в несколько раз меньше времени, чем при получении того же мегабайта, но одним запросом или десятью последовательными запросами из одного потока.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034700
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128,

Вы написали фигню. И было объяснено почему именно.
Если не доходит - перечитывайте мой ответ до понимания.
Если понимание не приходит, подумайте - почему в статистике выполнения есть CPU time и Elapsed time, но нет IO time?
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034708
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Вы написали фигню. И было объяснено почему именно.
Если не доходит - перечитывайте мой ответ до понимания." (С)

invm
нет IO time?

Потому что SQL сервер его не знает. Эту статистику даже система не знает, хотя и обладает возможностями ее узнать в частных случаях. Только СХД.
Косвенно эту статистику можно оценить через системные счетчики производительности. Но если СХД обслуживает несколько серверов эта информация Вам даст мало полезного.

Попробуйте все же погуглить и дать ответ на вопрос:
Различается ли нагрузка на СХД при чтении одного мегабайта одним запросом ввода-вывода от нагрузки при чтении этого же мегабайта десятью запросами ввода-вывода?
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034718
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
Потому что SQL сервер его не знает.
Если не знает, то как вы собрались это учитывать?

Осознайте простую вещь: единственный объективный критерий, по которому можно сравнивать производительность разных запросов, решающих одну и ту же задачу - это CPU time.
Все остальное - случайные значения на момент выполнения.

А если уж так хочется грубо оценить потенциальное влияние IO - выполните запрос в тех же тепличных условиях, но предварительно очистите BP.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034729
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm
Если не знает, то как вы собрались это учитывать?

Элементарно, Ватсон. Косвенным путем глядя на scan count, logical reads и physical reads.

Попробую пояснить на примере.
Есть табличка:
Код: plaintext
1.
2.
name		rows			reserved	data		index_size	unused
FactLoad	26781420            	10382184 KB	3208456 KB	7159760 KB	13968 KB
Код: sql
1.
SELECT * INTO #t FROM factload OPTION (MAXDOP 0)


Код: plaintext
1.
2.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 1 ms.
Table 'FactLoad'. Scan count  33 , logical reads  404638 , physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Код: sql
1.
SELECT * INTO #t FROM factload OPTION (MAXDOP 1)


Код: plaintext
1.
2.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.
Table 'FactLoad'. Scan count  1 , logical reads  402392 , physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Во-первых, сразу видим во сколько потоков выполнялся запрос (33-1=32).

Во-вторых, видим, что параллельный план запроса в данном случае потребовал 2246 дополнительных обращений к кешу данных. То есть, при недостатке памяти дважды с диска могло читаться 0.6% страниц. Таким процентом я готов пренебречь. А было бы 6% - это уже стало бы поводом для размышлений в случае многопользовательской системы.

invm
Все остальное - случайные значения на момент выполнения.

Данный пример заодно показывает, насколько Вы заблуждаетесь. После того, как вся таблица оказалась в кеше, все значения статистик ввода-вывода стабилизировались. То есть, они совсем не "случайные". Нужно просто уметь их правильно интерпретировать )))
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034734
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
Элементарно, Ватсон. Косвенным путем глядя на scan count, logical reads и physical reads.

Попробую пояснить на примере.
Не надо ничего объяснять на примерах. Вы просто физику процесса не понимаете.

IO есть физическое и логическое.
Затраты времени на логическое регистрируется в CPU time, потому что (какая неожиданность) логическим занимается CPU.
А на физическое - в ожиданиях PAGEIOLATCH*. Потому что поток ждет, когда завершатся инициированные им физические IO. Суммарно эти ожидания дадут время, затраченное на физические чтения и запись.

Именно поэтому нет отдельной статистики IO time. Именно поэтому количество IO бестолку учитывать при сравнении производительности разных запросов, ибо оно уже учтено в CPU time. А ожидания к сравнению производительности вообще никак не относятся.

Учите матчасть.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034740
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Вы просто физику процесса не понимаете." (с)

invm

Суммарно эти ожидания дадут время, затраченное на физические чтения и запись.

Они дадут погоду на Марсе, так как в общем случае, мы не знаем, что уже в кеше, а чего там нет.

В том то и дело, что для того, чтобы оценить нагрузку на СХД нам нужно проанализировать, количество страниц которые нужны запросу с одной стороны, и то, как часто наш сервер ходит на диск по sys.dm_io_virtual_file_stats.

На практике, мне еще приходилось порой гонять с завидной регулярностью fio, чтобы можно было аргументированно разбираться с администраторами СХД по поводу обещанных и фактических IOPS.

Впрочем мы начинали с того, как различается нагрузка на СХД при MAXDOP 0 и MAXDOP 1. И это я уже наглядно показал. Если все таблицы, используемые в запросе не могут поместиться в кеше - различается, так как читается разное количество страниц. А сколько реально прочиталось в процессе эксплуатации - смотрим уже в sys.dm_exec_query_stats и делаем выводы об этих запросах.

В DWH параллельное выполнение запросов - хорошо. В высоконагруженной многопользовательской системе - не факт. Потому что может быть важно не столько то, сколько ждет результата запроса конкретный Вася. А сколько в среднем времени ожидают выполнения своих запросов все пользователи включая тех, кто ждет завершения Васиного запроса.

"Учите матчасть." (С)
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40034798
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
Они дадут погоду на Марсе, так как в общем случае, мы не знаем, что уже в кеше, а чего там нет.
1. Внимательно перечитайте мой ответ. Можно несколько раз, пока не поймете.
2. И еще раз - учите матчасть.

Дальнейшая дискуссия не имеет смысла, пока не осознаете разницу между анализом быстродействия одного запроса и сравнением быстродействия разных запросов.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035432
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128,

гаданием на SQL метриках Вы не получите предсказание нагрузки СХД. Для получения ясной картины составьте нагрузочные сценарии, и по выполнению этих сценариев замеряйте нагрузку СХД.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035496
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав Колосов,

и даже нагрузочным сценарием не получу, если СХД обслуживает несколько серверов.
Но сравнивая метрики двух запросов смогу оценить вероятность того, что один из запросов создаст больше нагрузку на СХД, чем другой. С точки зрения оптимизации запросов, это может быть полезным. Не более того.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035673
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
Но сравнивая метрики двух запросов смогу оценить вероятность того, что один из запросов создаст больше нагрузку на СХД, чем другой.
О, уже какой-то прогресс. По крайней мере, нет речи об общем времени IO.
И по какой методике собрались определять эти вероятности?
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035674
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm,

Может хватит клоунады? Об общем времени IO спич вели исключительно Вы, тогда как я изначально вел речь только об оценке нагрузки на СХД при помощи статистик IO, что Вы считали и считаете бессмысленным.

P.S. Мы же вроде бы договорились о прекращении дискуссий о размере пиписек как здесь, так и в будущем?
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035691
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
Об общем времени IO спич вели исключительно Вы, тогда как я изначально вел речь только об оценке нагрузки на СХД при помощи статистик IO
Ваши слова:
ptr128
Во-первых, не временем исполнения, а временем загрузки CPU и IO.
И где тут СХД? Или для вас logical reads/writes не IO? Тогда дайте какой-нибудь пруф, что это так. Или объясните почему результаты statistics io содержат не только physical но и logical reads?
ptr128
Вы считали и считаете бессмысленным.
Ну так продемонстрируйте смысл и методику его определния. Именно при сравнении быстродействия двух запросов.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035697
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm
ptr128
Во-первых, не временем исполнения, а временем загрузки CPU и IO.
И где тут СХД?

А где тут время IO?
Или если я скажу, что схожу за хлебом в зависимости "от времени в пути и настроения", Вы решите, что я говорю об измерении настроения временем?
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035703
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm
Ну так продемонстрируйте смысл и методику его определния. Именно при сравнении быстродействия двух запросов.

22261187
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035766
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
А где тут время IO?
Я про время спрашивал? Я спрашивал как из Ваших слов понять, что речь ведется о СХД?
ptr128
И где там стравнение быстродействия двух запросов? Там сравнение сериального и параллельного плана одного и того же запроса. Причем, есть подозрение, что Вы не в курсе как вычитываются таблицы/индексы в параллельных планах.

Итого, ответа на
ptr128
Но сравнивая метрики двух запросов смогу оценить вероятность того, что один из запросов создаст больше нагрузку на СХД, чем другой.
Так и нет.
Только не нужно писать, что на самом деле тут идет речь о сравнении сериального и параллельного запроса.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035778
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm,

ответы все был даны выше. Дополнительные консультации за отдельную плату. До свидания.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035838
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
ответы все был даны выше. Дополнительные консультации за отдельную плату. До свидания.

Итак, ответов на поставленные вопросы как не было, так и нет. Есть только много гонора...

Попытка втюхать 22261187 как ответ и нечто полезное и высокомудрое - несостоятельна.
Ибо на заданный вопрос не отвечает и Вашу всезнающую голову так и не посетил банальный вопрос - каким образом параллельное полное сканирование таблицы может дать, при прочих равных, большее количество физических чтений, чем такое же сериальное?
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035864
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm,

лично с Вас, $20 за ответ. Реквизиты пришлю в ответ на письмо.

Ответ обещаю с примером, причем повторяемым.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035880
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128,

Ну докажите сначала, что Вы в состоянии дать адекватный пример. А то деньги возьмете и с приветом...
Хотя бы принцип его работы объясните.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035890
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm,

Попробуйте сами ответить на вопросы:
Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(1)?
Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(0)?
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035985
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ptr128
Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(1)?
Читается ли какой-то индекс таблицы в запросе SELECT * FROM table MAXDOP(0)?
Расшифруйте глубинный смысл данных вопросов.

Даже если Ваша таблица в обсуждаемом примере кластерная, физических чтений не будет больше, чем общее число страниц кластерного индекса. Потому что сервер не дурак и не будет поднимать с диска страницу, если она уже есть в BP.
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40035988
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm,

Я же Вам выше стоимость моих ответов озвучил. Жду в e-mail
...
Рейтинг: 0 / 0
Связать две таблицы join'ом при связи 1:М.
    #40036051
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
use master;
set ansi_nulls, quoted_identifier, xact_abort on;
go

create database TestData;
alter database TestData set recovery simple;
go

use TestData;
go

create table dbo.t_clustered (id int identity not null primary key, v int null, filler char(100) null);
create table dbo.t_heap (id int identity not null, v int null, filler char(100) null);

insert into dbo.t_clustered
 (v)
output
 inserted.v into dbo.t_heap (v)
 select top (1000000)
  1
 from
  master.dbo.spt_values a cross join
  master.dbo.spt_values b;

select
 sum(page_count) as t_clustered__total_pages,
 sum(case when index_level > 0 then page_count else 0 end) as t_clustered__nonleaf_pages
from
 sys.dm_db_index_physical_stats(db_id(), object_id('dbo.t_clustered'), null, null, 'detailed');

select
 sum(page_count) as t_heap__total_pages
from
 sys.dm_db_index_physical_stats(db_id(), object_id('dbo.t_heap'), null, null, 'detailed');
go

-- запретим prefetch и read ahead
dbcc traceon(652, -1);
dbcc traceon(8744, -1);
go

use master;
go

-- очистим BP от данных из TestData
alter database TestData set offline with rollback immediate;
alter database TestData set online;
go

print '--- Seril plan ------------------------------------';
declare @c bigint;
set statistics xml, io on;
select @c = count(v) from TestData.dbo.t_clustered option(maxdop 1);
select @c = count(v) from TestData.dbo.t_heap option(maxdop 1);
set statistics xml, io off;
go

-- очистим BP от данных из TestData
alter database TestData set offline with rollback immediate;
alter database TestData set online;
go

print '--- Parallel plan ------------------------------------';
declare @c bigint;
set statistics xml, io on;
select @c = count(v) from TestData.dbo.t_clustered option (use hint('enable_parallel_plan_preference'));
select @c = count(v) from TestData.dbo.t_heap option (use hint('enable_parallel_plan_preference'));
set statistics xml, io off;
go

use master;
alter database TestData set single_user with rollback immediate;
drop database TestData;
go

dbcc traceoff(652, -1);
dbcc traceoff(8744, -1);
go



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
--- Seril plan ------------------------------------
Table 't_clustered'. Scan count 1, logical reads 14495, physical reads 14495, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

Table 't_heap'. Scan count 1, logical reads 14493, physical reads 14493, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

--- Parallel plan ------------------------------------
Table 't_clustered'. Scan count 5, logical reads 14652, physical reads 14547, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

Table 't_heap'. Scan count 5, logical reads 14493, physical reads 14493, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
...
Рейтинг: 0 / 0
56 сообщений из 56, показаны все 3 страниц
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Связать две таблицы join'ом при связи 1:М.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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