powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Сравнение loop join с hasj join
13 сообщений из 38, страница 2 из 2
Сравнение loop join с hasj join
    #39576898
Prolog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andy_OLAPПосле того, как какой-нибудь падаван сделает with index, а затем магистр Йода у индекса таблицы disable сделает.
И выдаст сервер сообщение 315 , и не сделает ничего, руками в стороны разведя и вздохнув всеми CPU.
И присоединится наш коллега к ситхам, и пошлет Дарта Вейдера с отборным легионом вырезать все хинты из кода...
Простите меня за мою дремучесть, но я не знаю, кто такие Дарт Вейдер, Йод, ситхи и падаван. Однако ваша фраза "вырезать все хинты из кода" меня очень насмешила. То есть, если в один прекрасный день Йод закроет доступ к одному из MS SQL серверов, и вы получите набор ошибок типа: "Server not found", "Login failed" или "General Network Error", то тогда Дарт Вейдер пойдёт переписывать данные из баз данных в гросбухи, после чего откажется от использования серверов?

На улицу выходить не стоит - вдруг какой-нибудь Йод уронить вам кирпич на голову. Дома также находится не стоит: может взорваться газ или ударить ток. Короче, опять приходим к "Жизнь - абсолютное зло".

За последние лет 15 я читал, что: "кластерные индексы абсолютное зло", "триггеры абсолютное зло", "суррогатные ключи абсолютное зло", "внешние ключи абсолютное зло", "функции абсолютное зло", "представления абсолютное зло", короче, всего и не перечислишь. И ничего, как-то живу со всем этим.

Я не могу себе представить, как из-за disable trigger, можно отказаться от использования хинтов. Мне кажется проще Йоду надавать по рукам.
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39576902
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Prolog
Я не могу себе представить, как из-за disable trigger, можно отказаться от использования хинтов. Мне кажется проще Йоду надавать по рукам.
Энди_Олап таким витиеватым языком имел в виду то, что по его мнению хинты плохо, потому, что накладывают на команду разработчиков некие административные расходы.

Например, если один человек напишет LOOP JOIN, а другой, внезапно, отключит индекс на большой таблице по полю соединения, то означенный LOOP сразу резко просядет в производительности против HASHa. Или если какой-то менее опытный боец, не глядя на LOOP напишет хинт INDEX= , то все полетит точно также.

В принципе, все хинтоненавистники строят свои доводы на том, что "вот придет рукожоп" или "вот случится странное" и тогда все будет плохо.

Вариант, что коды проходят ревью, что статистика постоянно обновляется, индексы постоянно ребилдятся, что, в конце-концов, на работу наняты не рукожопы, а люди, способные заметить наличие хинтов в запрос - почему то никогда не рассматривается.
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39576969
Гигабайт Мегабайтович Килобайтов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileProlog
Я не могу себе представить, как из-за disable trigger, можно отказаться от использования хинтов. Мне кажется проще Йоду надавать по рукам.
Энди_Олап таким витиеватым языком имел в виду то, что по его мнению хинты плохо, потому, что накладывают на команду разработчиков некие административные расходы.

Например, если один человек напишет LOOP JOIN, а другой, внезапно, отключит индекс на большой таблице по полю соединения, то означенный LOOP сразу резко просядет в производительности против HASHa. Или если какой-то менее опытный боец, не глядя на LOOP напишет хинт INDEX= , то все полетит точно также.

В принципе, все хинтоненавистники строят свои доводы на том, что "вот придет рукожоп" или "вот случится странное" и тогда все будет плохо.

Вариант, что коды проходят ревью, что статистика постоянно обновляется, индексы постоянно ребилдятся, что, в конце-концов, на работу наняты не рукожопы, а люди, способные заметить наличие хинтов в запрос - почему то никогда не рассматривается.
понимаешь люди приходят, уходят а системы остаются. И если в одно время команда разработчиков была грамотная, то это не означает, что через три года она же останется в том составе. И таки всегда найдётся юный падаван, который таки умудриться протолкнуть свою "нетленку" . Согласен, правильный процесс разработки таки сокращает риски , но не исключает, а вот уже стоимость таки случившегося риска намного более значима, чем усилия по его предотвращению. И, ихма, таки если возникла необходимость хинтов то проблема назрела, и её надо решать не хинтом, а пересмотром архитектуры, алгоритмов и всего остального. Хинт - это гвоздь на некоторое время, за которое надо понять проблему и решить без хинтов.
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39577004
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гигабайт Мегабайтович КилобайтовХинт - это гвоздь на некоторое время, за которое надо понять проблему и решить без хинтов.
Однако, это "некоторое время" может быть всего лишь тем временем, пока БД растет до эксплуатационных размеров, а потом план запроса сам превращается в тот, который форсирует данный хинт.
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39577024
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Работал я как-то пару лет в команде, где хинтовали почты каждый запрос. Под строгим контролем архитектора, само собой.

Более 10 лет так живут, полет отличный. Один из топовых, в своем бизнесе, холдингов. И вот что они делают не так?
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39577031
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileРаботал я как-то пару лет в команде, где хинтовали почты каждый запрос. Под строгим контролем архитектора, само собой.

Так и у меня такое, не редко происходит. Причина в том, что когда система только запускается, количество записей в справочниках может на порядки превышать количество записей в операциях. Тогда как уже через год-другой эксплуатации все будет с точностью наоборот. Естественно, оптимизировать индексы под корявые планы запроса, которые возникают при текущих статистиках, нет никакого желания. Вот и лепим хинты, чтобы PM не пришлось объяснять клиенту, что если на 1000 операциях отчет выполняется 4 секунды, то это не значит, что на 1 млн. операциях он будет выполняться час.
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39577032
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, в моем случае, коллеги сильно заморочены на миллисекундах были. Вот и кроили копеечки везде, где могли.
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39577049
dao
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileРаботал я как-то пару лет в команде, где хинтовали почты каждый запрос. Под строгим контролем архитектора, само собой.

Более 10 лет так живут, полет отличный. Один из топовых, в своем бизнесе, холдингов. И вот что они делают не так?
если там архитектору платят как топ-менеджменту , то наверное делают правильно ))
разговор как раз о таких компаниях, в которых за 3-4 года меняется состав полностью.
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39577051
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileНу, в моем случае, коллеги сильно заморочены на миллисекундах были. Вот и кроили копеечки везде, где могли.
А вот от этого меня давно отучили. IMHO, если оптимизатор тупит, то лучше явно разбить один запрос на несколько с временными таблицами, чем рисковать, прописывая хинты. При правильном подходе, результат будет идентичный, но зато надежней.
Один из ярких примеров - квитанция для физических лиц по ЖКУ, которая в процессе оптимизации превратилась из двух запросов (заголовок и детали) в восемь. Отдельно пришлось собирать услуги, потребление по точкам учета, показания индивидуальных приборов учета, перерасчеты, потребление ОДН, показания коллективных приборов учета, и распределение ОДН.
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39577260
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Prologaleks222,
Из области: "Жизнь - абсолютное зло: в её результате наступает смерть".
Зачем-то хинты придумали, и с их помощью запросы работают быстрее. И это факт. Без хинтов и медленно - это абсолютное добро, с хинтами и быстро - это абсолютное зло. Может быть вы просто не умеете ими пользоваться?

Вопрос не про хинты. Вопрос про соединения: "Почему при меньшем количестве Reads и CPU соединение с hash выполняется медленнее, чем loop"? Хинты для того, чтобы получить статистику при разных типах соединений.

1. Глупенький, отменить смерть - ты не в силах. А не использовать хинты - вполне.

2.
Prolog[/src]
результат statistics io:
Код: sql
1.
2.
Table 'Workfile'.    Scan count 0, logical reads 0,   physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'.   Scan count 0, logical reads 0,   physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 



Думаешь 'Workfile/Worktable создаются святым духом?
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39577302
stgh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Prolog,

тестировалось на 2005 и на 2017

везде loop медленнее.

Код: 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.
set nocount on;
use [tempdb]
go

if exists (select 1 from sys.tables where object_id=OBJECT_ID(N'dbo.instruments')) drop table dbo.instruments;
create table dbo.instruments ( instruments_id int identity(1,1) not null, name sysname not null default (CAST(NEWID() as sysname)) ,assettype_id int not null default (ABS(CHECKSUM(NEWID()) % 11) + 1) );
go
if exists (select 1 from sys.tables where object_id=OBJECT_ID(N'dbo.assettypes')) drop table dbo.assettypes;
create table dbo.assettypes ( assettype_id int identity(1,1) not null, name sysname not null default (CAST(NEWID() as sysname)), primary key clustered (assettype_id) )
go

insert into dbo.assettypes default values;
go 11

insert into dbo.instruments default values;
go 50759



set statistics io on;
set statistics time on;

select i.name,t.name from instruments i left loop join assettypes t on t.assettype_id = i.assettype_id option (force order,maxdop 1);

print '---'

select i.name,t.name from instruments i left hash join assettypes t on t.assettype_id = i.assettype_id option (force order,maxdop 1)

set statistics time off;
set statistics io off;
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39577309
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Естественно. Ты же сделал всё, чтобы этот луп был медленнее. Яб удивился, если бы он в твоих запросах был бы быстрее.
...
Рейтинг: 0 / 0
Сравнение loop join с hasj join
    #39577319
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коллеги, давайте раз и на всегда внесем ясность. Хинт к запросу, это не какая-то там магия-шмагия, которая как-то что-то улучшает.
"Чет медленно, хинтану луп. Ой не вышло, хинтану хеш" - ТАК НЕ РАБОТАЕТ.

Попытаюсь пояснить по-рабоче-крестьянске.

Слева у вас маленькая таблица, справа здоровенная. В большой таблице поле по связи индексировано . Используете луп. При этом, большая и маленькая, понятия, конечно условные. Но вообще, большая, это значит на порядки больше. Слева таблица больше чем справа? Луп плохой. Нет индекса на большой таблице? Луп плохой.

Далее, у вас два упорядоченных по связываемым полям набора данных (читай есть индексы) и размеры сопоставимы ? Используете мердж.

Во всех остальных случаях используете хеш. Всё.
...
Рейтинг: 0 / 0
13 сообщений из 38, страница 2 из 2
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Сравнение loop join с hasj join
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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