2010-04-04 5 views
0

Sql Server 2005:процедура SQL Server оптимизация

Option: 1 

    CREATE TABLE #test 
     (customerid, orderdate, field1 INT, field2 INT, field3 INT) 

    CREATE UNIQUE CLUSTERED INDEX Idx1 ON #test(customerid) 
    CREATE INDEX Idx2 ON #test(field1 DESC) 
    CREATE INDEX Idx3 ON #test(field2 DESC) 
    CREATE INDEX Idx4 ON #test(field3 DESC) 

    INSERT INTO #test 
     (customerid, orderdate, field1 INT, field2 INT, field3 INT) 
    SELECT 
     customerid, orderdate, field1, field2, field3 FROM 
    ATABLERETURNING4000000ROWS 
 

compared to

Option: 2 

    CREATE TABLE #test 
     (customerid, orderdate, field1 INT, field2 INT, field3 INT) 

    INSERT INTO #test 
     (customerid, orderdate, field1 INT, field2 INT, field3 INT) 
    SELECT 
     customerid, orderdate, field1, field2, field3 FROM 
    ATABLERETURNING4000000ROWS 

    CREATE UNIQUE CLUSTERED INDEX Idx1 ON #test(customerid) 
    CREATE INDEX Idx2 ON #test(field1 DESC) 
    CREATE INDEX Idx3 ON #test(field2 DESC) 
    CREATE INDEX Idx4 ON #test(field3 DESC) 
 

Когда мы используем второй вариант он работает около 50% быстрее. Почему это?

ответ

1

От SQL Server Query Processing Team:

Для того, чтобы построить б-дерево для индекса, мы должны сначала отсортировать данные из источника. Поток должен сканировать источник, сортировать его (если возможно - в памяти *), а затем построить b-дерево из сортировки.
Зачем нам сначала сортировать до построения b-дерева? Теоретически нам не нужно сортировать, мы могли бы использовать обычный DML и напрямую вставлять данные в индекс in-build (без сортировки), но в этом случае мы будем делать случайные вставки, случайные вставки в b-tree требуют сначала поиск b-дерева для правильного листового узла, а затем вставка данных. И при поиске b-дерева достаточно быстро, делая это, прежде чем каждая вставка далека от оптимальной..

Your indexes are B+ trees.

Первый запрос требует поиски в B + деревья для каждой записи, а затем изменяющие B + деревья.

Второй запрос будет сортировать данные, необходимые для каждого индекса, в свою очередь, в соответствии с конкретным индексом, а деревья B + - constructed very efficiently.

1

Поскольку вы вставляете строки перед добавлением индексов. Уникальный индекс требует, чтобы система выполняла проверки уникальности для вновь добавленных строк и вставки, система должна обновлять различные записи индекса. Не нужно выполнять работу с проверками уникальности быстрее, но при создании дубликатов во втором параметре вы создадите дубликаты значений.

+0

Спасибо. На самом деле у нас есть группа клиентов по таблице ATABLERETURNING4000000ROWS, которая обеспечила бы уникальность. – stackoverflow

+0

@stackoverflow: даже если вы удалите уникальное ограничение, второй вариант будет быстрее. Я добавил ответ о том, почему. –

Смежные вопросы