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 список ещё меньше, но это нужно проверять или дождаться окончания этого цикла статей.
Это был ответ к комментарию, сорри.
Вы же понимаете, что Brent Ozar (который является автором оригинала) вряд ли увидит ваш вопрос? Если вам всё же важно выяснить причину удаления на SO, вы можете задать свой вопрос автору лично — он там даже отвечает в комментариях.
Sign up to leave a comment.
7 вещей, которые разработчик должен знать о SQL Server