Изменения в упорядочивании данных между SQL Server 2000 и 2012
Моя компания недавно переместила.NET 1.1/SQL SERVER 2000 веб-приложения в SQL Server 2012. У нас было несколько обращений за поддержкой, касающихся необычного поведения - особенно с запросами хранимой процедуры без пунктов ORDER BY.
Я ценю функциональность наличия, полагающуюся на упорядочивание этих типов запросов, плохая практика - но кто-либо знает, существует ли официальная документация Microsoft на изменениях упорядочивания значения по умолчанию между версиями SQL Server?
SQL Server 2012 не гарантирует порядок строк, возвращаемых в SQL 2012. Так же как и 2000. (Цитата, которую я нашел для этого, на самом деле 2005, но достаточно близко.)
По сути, SQL Server Query Optimizer гарантирует, что внутренний оператор в дереве запросов будет обрабатывать его входные данные в формате особый порядок. Нет соответствующей гарантии, что выход этого оператора будет означать, что следующий оператор в дереве запросов выполняется в таком порядке. Правила переупорядочивания могут и будут нарушать это предположение (и делай это, когда тебе неудобно, - разработчик ;). Пожалуйста, поймите, что при повторном заказе операций на найти более эффективный план, мы можем привести поведение заказа к тому. изменение для промежуточных узлов дерева. Если вы сделали операцию в дереве, которое предполагает определенный промежуточный порядок, оно может перерыв.
В основном: Тебе повезло до сих пор, и он наконец-то укусил тебя.
Эта статья Ицика Бен-Гана может тебе помочь. Пример:
Один из самых важных аспектов сетов подразумевается в Cantor's Определение. Он не упоминает порядок элементов в наборе. потому что заказ не важен. Это один из самых сложных понятия, которые люди должны понимать, когда запрашивают таблицу-именно, понимая, что нет никаких гарантий того, что запрашиваемые данные будет потребляться в определенном порядке. Например, некоторые люди предположим, что когда они запрашивают таблицу с кластерным индексом, они получат данные обратно в порядке следования кластерных индексов. С языка перспективы, это не гарантировано, потому что то, что вы запрашиваете, это и то, что ты получишь обратно, это набор. SQL Server знает, что язык не предоставляет никаких гарантий заказа, поэтому он сканирует данные. в любом порядке, который ему нравится, в том числе и не в порядке сгруппированных индексов. Люди часто используют методы, которые нарушают установленный и реляционный порядок. понятия в том смысле, что корректность результатов зависит от данных потребляется в порядке индексов, который SQL-сервер никогда не гарантировал. В своих эксклюзивных web-статьях я привел пару классических примеров. "Назначение и задание многорядных переменных по" и "Заказал Обновление и Set-Based Solutions to Running Aggregates".
Бен-Ган написал учебник SQL Server 70-461 и подчеркивает этот момент и там.
Хотелось бы мне рассказать вам что-нибудь получше, но... нет, нет никакого "порядка по умолчанию", поэтому не стоит на него полагаться, и он не документирован.
.Заказ комплектов является неопределенным и недокументированным . "Недокументированное" в данном случае означает две вещи:
- Мы не сможем предоставить вам конкретную ссылку или кавычки с подробным описанием изменений или того, каким будет новое поведение, так как оно явно не объявлено. Это по замыслу, и в соответствии с концепцией реляционного "множества".
- Поскольку это не документировано, Microsoft вольна изменять поведение в любое время по своему усмотрению. Иначе ничем не примечательный патч, поставляемый через Windows Update, может изменить это (не то, что у него есть, а то, что он может не нарушая никаких политик). Даже если вы дразните определенное поведение сегодня, вы не должны полагаться на него, потому что оно может измениться завтра без предупреждения.
Эта свобода важна для производителей баз данных, таких как Microsoft. Она дает им возможность вводить новшества и вносить изменения, влияющие на производительность, в свой продукт.
Это подводит меня к следующему моменту. Долгое время существовала идея, что запросы без пункта ORDER BY будут возвращать результаты в соответствии с первичным ключом (кластерным индексом) основной таблицы в запросе. Это false , и всегда было ложью. Часто результаты возвращаются таким образом, но только потому, что это обычно самый быстрый способ обслуживания запроса. Но из этого всегда были исключения: покрытие индексов, сканирование круглых таблиц, сложные соединения и подзапросы, где "главная" таблица запроса может изменяться в зависимости от того, какая статистика была составлена в этом месяце, и т.д.
В последние годы новые концепции, такие как Recursive CTE, Windowing Functions и APPLY, создали множество новых ситуаций, в которых порядок следования кластерных индексов уже не является самым быстрым способом обслуживания запроса. Это влияние выходит за рамки только запросов, которые используют эти новые возможности. Так как механизм запросов добавляет сложность, чтобы приспособиться к новым функциям, он получает новые инструменты для поддержки тех функций, которые также полезны при подготовке планов для старых запросов, а также.
. Просто чтобы добавить больше
В sql 2k8 enterprise есть новая функция, называемая mery go around.
Эта функция, по сути, повторно использует запрос сканирования таблицы из другого потока.
http://www.sanssql.com/2013/07/merry-go-round-scans-in-sql-server.html