Comments 13
6. «WITH (NOLOCK)» не означает, что блокировок не будет вообще
2. Избегайте использования ORDER BY; сортируйте данные в приложении
Эти два пункта поразили до глубины души
Расшифрую:
по поводу WITH NOLOCK. Поразило не то что будут блокировки, а то, что кто-то этой анафемой не только всерьез пользуется, но еще и рассчитывает, что при этом не будет блокировок
по поводу сортировок — следующий шаг известен: видимо джойнить данные также следует в приложении
по поводу WITH NOLOCK. Поразило не то что будут блокировки, а то, что кто-то этой анафемой не только всерьез пользуется, но еще и рассчитывает, что при этом не будет блокировок
по поводу сортировок — следующий шаг известен: видимо джойнить данные также следует в приложении
А что вас удивляет в сортировках? Ведь если что-то можно выполнить на клиенте, то зачем выполнять это на сервере? Это как если бы в многопользовательской игре графика вычислялась бы на серверах, а клиентам посылались просто картинки.
Я всерьез пользуюсь. Да и не только я. В некоторых случаях падение TTFB с десятков секунд до миллисекунд. Есть вполне конкретные блокировки и конкретные кейсы, в которых этот хинт замечательно помогает.
На одном из этапов своей карьеры разработчика вы можете начать использовать хинт WITH (NOLOCK) повсеместно, поскольку с ним ваши запросы выполняются быстрее.
Я не считаю подобную практику разумной, только и всего (особенно «повсеместно»)
В исключительных случаях использовать можно (предварительно тщательно продумав все последствия)
По поводу WITH (NOLOCK) — многие пользуются. На счёт того, что думают, что блокировок никаких не накладывает — тоже есть пример (и не один).
По поводу ORDER BY — никто не говорит, что им нельзя пользоваться. ИМХО, Брент, в своём UPD, достаточно чётко высказал свою позицию — «Если без него можно обойтись, лучше обойтись». Я с ним согласен. Серверу баз данных и так есть чем себя занять, а порядок строк, в ряде случаев важен не с точки зрения логики приложения/запроса, а только для пользователя — вот пусть у этого конкретного пользователя, в этих случаях, и сортируется.
По поводу ORDER BY — никто не говорит, что им нельзя пользоваться. ИМХО, Брент, в своём UPD, достаточно чётко высказал свою позицию — «Если без него можно обойтись, лучше обойтись». Я с ним согласен. Серверу баз данных и так есть чем себя занять, а порядок строк, в ряде случаев важен не с точки зрения логики приложения/запроса, а только для пользователя — вот пусть у этого конкретного пользователя, в этих случаях, и сортируется.
7. Производительность UDF оставляет желать лучшего
Следует различать скалярные, табличные-встроенные и табличные-multi-statement пользовательские функции. Всё что вы описали относится к скалярным функциям, но не к встроенным.
Я при переводе ориентировался на ту статью, на которую ссылался автор поста, а тот, в свою очередь, вот на эту. А в этой последней статье, прилеплена pdf-ка, в которой есть вот такой лист:
Ну и, соответственно, написал про UDF (сорри за длинное объяснение, хотел всю цепочку показать).
Если вы располагаете другой информацией, помогите, пожалуйста, правильно переформулировать 7-й пункт :).
Ну и, соответственно, написал про UDF (сорри за длинное объяснение, хотел всю цепочку показать).
Если вы располагаете другой информацией, помогите, пожалуйста, правильно переформулировать 7-й пункт :).
Следим за руками. По вашим ссылкам имеем:
Статья 1: Parallel Query Execution Presentation за авторством Craig Freedman от 17 Apr 2007
Статья 2: Forcing a Parallel Query Execution Plan за авторством Paul White от 23 Dec 2011
Разница в датах наводит на мысль, что статья 1 устарела (6 лет всё-таки и 2005 SQL). Если немного вчитаться в статью 2, то в разделе «Parallelism-Inhibiting Components» находим строчку «The information presented above is based on the original list published by Craig Freedman, and updated for 2008 R2.» И набор блокирующих паралельный план запроса компонентов выглядит так:
И там я не вижу всех UDF, а только scalar (sql и CLR) Т.е. за 1.5 версии список немного уменьшился. Возможно для 2012 SQL список ещё меньше, но это нужно проверять или дождаться окончания этого цикла статей.
Это был ответ к комментарию, сорри.
Статья 1: Parallel Query Execution Presentation за авторством Craig Freedman от 17 Apr 2007
Статья 2: Forcing a Parallel Query Execution Plan за авторством Paul White от 23 Dec 2011
Разница в датах наводит на мысль, что статья 1 устарела (6 лет всё-таки и 2005 SQL). Если немного вчитаться в статью 2, то в разделе «Parallelism-Inhibiting Components» находим строчку «The information presented above is based on the original list published by Craig Freedman, and updated for 2008 R2.» И набор блокирующих паралельный план запроса компонентов выглядит так:
That list changes from version to version, but for example these things make the whole plan serial on SQL Server 2008 R2 SP1:
— Modifying the contents of a table variable (reading is fine)
— Any T-SQL scalar function (which are evil anyway)
— CLR scalar functions marked as performing data access (normal ones are fine)
— Random intrinsic functions including OBJECT_NAME, ENCYPTBYCERT, and IDENT_CURRENT
— System table access (e.g. sys.tables)
И там я не вижу всех UDF, а только scalar (sql и CLR) Т.е. за 1.5 версии список немного уменьшился. Возможно для 2012 SQL список ещё меньше, но это нужно проверять или дождаться окончания этого цикла статей.
Это был ответ к комментарию, сорри.
UFO just landed and posted this here
Вы же понимаете, что Brent Ozar (который является автором оригинала) вряд ли увидит ваш вопрос? Если вам всё же важно выяснить причину удаления на SO, вы можете задать свой вопрос автору лично — он там даже отвечает в комментариях.
Sign up to leave a comment.
7 вещей, которые разработчик должен знать о SQL Server