Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
Andy_OLAPПосле того, как какой-нибудь падаван сделает with index, а затем магистр Йода у индекса таблицы disable сделает. И выдаст сервер сообщение 315 , и не сделает ничего, руками в стороны разведя и вздохнув всеми CPU. И присоединится наш коллега к ситхам, и пошлет Дарта Вейдера с отборным легионом вырезать все хинты из кода... Простите меня за мою дремучесть, но я не знаю, кто такие Дарт Вейдер, Йод, ситхи и падаван. Однако ваша фраза "вырезать все хинты из кода" меня очень насмешила. То есть, если в один прекрасный день Йод закроет доступ к одному из MS SQL серверов, и вы получите набор ошибок типа: "Server not found", "Login failed" или "General Network Error", то тогда Дарт Вейдер пойдёт переписывать данные из баз данных в гросбухи, после чего откажется от использования серверов? На улицу выходить не стоит - вдруг какой-нибудь Йод уронить вам кирпич на голову. Дома также находится не стоит: может взорваться газ или ударить ток. Короче, опять приходим к "Жизнь - абсолютное зло". За последние лет 15 я читал, что: "кластерные индексы абсолютное зло", "триггеры абсолютное зло", "суррогатные ключи абсолютное зло", "внешние ключи абсолютное зло", "функции абсолютное зло", "представления абсолютное зло", короче, всего и не перечислишь. И ничего, как-то живу со всем этим. Я не могу себе представить, как из-за disable trigger, можно отказаться от использования хинтов. Мне кажется проще Йоду надавать по рукам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2017, 15:11 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
Prolog Я не могу себе представить, как из-за disable trigger, можно отказаться от использования хинтов. Мне кажется проще Йоду надавать по рукам. Энди_Олап таким витиеватым языком имел в виду то, что по его мнению хинты плохо, потому, что накладывают на команду разработчиков некие административные расходы. Например, если один человек напишет LOOP JOIN, а другой, внезапно, отключит индекс на большой таблице по полю соединения, то означенный LOOP сразу резко просядет в производительности против HASHa. Или если какой-то менее опытный боец, не глядя на LOOP напишет хинт INDEX= , то все полетит точно также. В принципе, все хинтоненавистники строят свои доводы на том, что "вот придет рукожоп" или "вот случится странное" и тогда все будет плохо. Вариант, что коды проходят ревью, что статистика постоянно обновляется, индексы постоянно ребилдятся, что, в конце-концов, на работу наняты не рукожопы, а люди, способные заметить наличие хинтов в запрос - почему то никогда не рассматривается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2017, 15:16 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
CammomileProlog Я не могу себе представить, как из-за disable trigger, можно отказаться от использования хинтов. Мне кажется проще Йоду надавать по рукам. Энди_Олап таким витиеватым языком имел в виду то, что по его мнению хинты плохо, потому, что накладывают на команду разработчиков некие административные расходы. Например, если один человек напишет LOOP JOIN, а другой, внезапно, отключит индекс на большой таблице по полю соединения, то означенный LOOP сразу резко просядет в производительности против HASHa. Или если какой-то менее опытный боец, не глядя на LOOP напишет хинт INDEX= , то все полетит точно также. В принципе, все хинтоненавистники строят свои доводы на том, что "вот придет рукожоп" или "вот случится странное" и тогда все будет плохо. Вариант, что коды проходят ревью, что статистика постоянно обновляется, индексы постоянно ребилдятся, что, в конце-концов, на работу наняты не рукожопы, а люди, способные заметить наличие хинтов в запрос - почему то никогда не рассматривается. понимаешь люди приходят, уходят а системы остаются. И если в одно время команда разработчиков была грамотная, то это не означает, что через три года она же останется в том составе. И таки всегда найдётся юный падаван, который таки умудриться протолкнуть свою "нетленку" . Согласен, правильный процесс разработки таки сокращает риски , но не исключает, а вот уже стоимость таки случившегося риска намного более значима, чем усилия по его предотвращению. И, ихма, таки если возникла необходимость хинтов то проблема назрела, и её надо решать не хинтом, а пересмотром архитектуры, алгоритмов и всего остального. Хинт - это гвоздь на некоторое время, за которое надо понять проблему и решить без хинтов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2017, 16:20 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
Гигабайт Мегабайтович КилобайтовХинт - это гвоздь на некоторое время, за которое надо понять проблему и решить без хинтов. Однако, это "некоторое время" может быть всего лишь тем временем, пока БД растет до эксплуатационных размеров, а потом план запроса сам превращается в тот, который форсирует данный хинт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2017, 16:51 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
Работал я как-то пару лет в команде, где хинтовали почты каждый запрос. Под строгим контролем архитектора, само собой. Более 10 лет так живут, полет отличный. Один из топовых, в своем бизнесе, холдингов. И вот что они делают не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2017, 17:20 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
CammomileРаботал я как-то пару лет в команде, где хинтовали почты каждый запрос. Под строгим контролем архитектора, само собой. Так и у меня такое, не редко происходит. Причина в том, что когда система только запускается, количество записей в справочниках может на порядки превышать количество записей в операциях. Тогда как уже через год-другой эксплуатации все будет с точностью наоборот. Естественно, оптимизировать индексы под корявые планы запроса, которые возникают при текущих статистиках, нет никакого желания. Вот и лепим хинты, чтобы PM не пришлось объяснять клиенту, что если на 1000 операциях отчет выполняется 4 секунды, то это не значит, что на 1 млн. операциях он будет выполняться час. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2017, 17:26 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
Ну, в моем случае, коллеги сильно заморочены на миллисекундах были. Вот и кроили копеечки везде, где могли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2017, 17:29 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
CammomileРаботал я как-то пару лет в команде, где хинтовали почты каждый запрос. Под строгим контролем архитектора, само собой. Более 10 лет так живут, полет отличный. Один из топовых, в своем бизнесе, холдингов. И вот что они делают не так? если там архитектору платят как топ-менеджменту , то наверное делают правильно )) разговор как раз о таких компаниях, в которых за 3-4 года меняется состав полностью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2017, 17:50 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
CammomileНу, в моем случае, коллеги сильно заморочены на миллисекундах были. Вот и кроили копеечки везде, где могли. А вот от этого меня давно отучили. IMHO, если оптимизатор тупит, то лучше явно разбить один запрос на несколько с временными таблицами, чем рисковать, прописывая хинты. При правильном подходе, результат будет идентичный, но зато надежней. Один из ярких примеров - квитанция для физических лиц по ЖКУ, которая в процессе оптимизации превратилась из двух запросов (заголовок и детали) в восемь. Отдельно пришлось собирать услуги, потребление по точкам учета, показания индивидуальных приборов учета, перерасчеты, потребление ОДН, показания коллективных приборов учета, и распределение ОДН. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.12.2017, 17:53 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
Prologaleks222, Из области: "Жизнь - абсолютное зло: в её результате наступает смерть". Зачем-то хинты придумали, и с их помощью запросы работают быстрее. И это факт. Без хинтов и медленно - это абсолютное добро, с хинтами и быстро - это абсолютное зло. Может быть вы просто не умеете ими пользоваться? Вопрос не про хинты. Вопрос про соединения: "Почему при меньшем количестве Reads и CPU соединение с hash выполняется медленнее, чем loop"? Хинты для того, чтобы получить статистику при разных типах соединений. 1. Глупенький, отменить смерть - ты не в силах. А не использовать хинты - вполне. 2. Prolog[/src] результат statistics io: Код: sql 1. 2. Думаешь 'Workfile/Worktable создаются святым духом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2017, 09:12 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2017, 10:36 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
Естественно. Ты же сделал всё, чтобы этот луп был медленнее. Яб удивился, если бы он в твоих запросах был бы быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2017, 10:58 |
|
||
|
Сравнение loop join с hasj join
|
|||
|---|---|---|---|
|
#18+
Коллеги, давайте раз и на всегда внесем ясность. Хинт к запросу, это не какая-то там магия-шмагия, которая как-то что-то улучшает. "Чет медленно, хинтану луп. Ой не вышло, хинтану хеш" - ТАК НЕ РАБОТАЕТ. Попытаюсь пояснить по-рабоче-крестьянске. Слева у вас маленькая таблица, справа здоровенная. В большой таблице поле по связи индексировано . Используете луп. При этом, большая и маленькая, понятия, конечно условные. Но вообще, большая, это значит на порядки больше. Слева таблица больше чем справа? Луп плохой. Нет индекса на большой таблице? Луп плохой. Далее, у вас два упорядоченных по связываемым полям набора данных (читай есть индексы) и размеры сопоставимы ? Используете мердж. Во всех остальных случаях используете хеш. Всё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2017, 11:25 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39576898&tid=1690593]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 221ms |
| total: | 375ms |

| 0 / 0 |
