Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
И да, хотите экономить место, делайте нормализацию данных в чар-полях, там стопудово не уникальные значение.

З.Ы. И, возможно, для PLDate подойтет тип smalldatetime, если вам не нужна точность более минуты.
6 май 13, 13:47    [14262677]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Сергей Викт.
Member

Откуда: Москва
Сообщений: 888
Гавриленко Сергей Алексеевич
И да, хотите экономить место, делайте нормализацию данных в чар-полях, там стопудово не уникальные значение.

З.Ы. И, возможно, для PLDate подойтет тип smalldatetime, если вам не нужна точность более минуты.


Безусловно неуникальные. И про точность вы тоже верно подметили. Пойду к разработчикам WMS-ки спрашивать чем им чревато то, что я изменю типы данных:)
6 май 13, 13:49    [14262686]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
Сергей Викт.
alexeyvg, т.е если создать такой индекс, как вы описали и в запросе указать WITH INDEX, должно проскакивать быстрее?
Без всякого WITH INDEX он должен использоваться и должно быть быстрее.

Я честно говоря не понимаю, почему используется index seek по кластерному индексу в вашем запросе - там диапазон дат за несколько месяцев, селективность не должна быть хорошей... В общем, нужно смотреть на всё вместе: планы, стоимости запросов, частота запросов для разных параметров и разной стоимости и т.п., тут же много факторов.

Сергей Викт.
Просто важный момент освободить место на жестких дисках:(
Это другая задача, экономить место и повысить скорость часто противоречат друг другу...

Самое главное - наборайте статистику запросов от приложения. Возможно, самое эффективное будет поменять кластерный инедкс и удалить все остальные, кто знает? Тогда и место съэкономится, и скорость возрастёт.

Я имею в виду, не делать индекс
[PLType] , [PLDate] INCLUDE [Article], [BPrice]
а изменить кластерный индекс на:
[PLType], [PLDate], [Article]
вместо:
[PLDate], [PLType], [Article]

Но это может замедлить вставку данных, если типично вставляются данные с вохзрастающим PLDate
6 май 13, 14:01    [14262788]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
Сергей Викт.
Гавриленко Сергей Алексеевич
И да, хотите экономить место, делайте нормализацию данных в чар-полях, там стопудово не уникальные значение.

Пойду к разработчикам WMS-ки спрашивать чем им чревато то, что я изменю типы данных:)
Даже если нельзя отказаться от строковых полей, наверняка нужно и можно заменить char на varchar, если только длинна строк во всех записях не одинаковая. Тогда можно съэкономить много места, потенциально в разы.
6 май 13, 14:05    [14262819]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
ROLpogo
Member

Откуда: Реутов
Сообщений: 219
Гавриленко Сергей Алексеевич
ROLpogo
Гавриленко Сергей Алексеевич,

Я предложил свой вариант решения задачи "освобождения места на диске". При переносе кластерного на ID мы срезаем порядка 10 Гб с каждого некластерного.
Придется все равно сделать unique constraint по полям нынешнего кластерного индекса, т.е. сделать четверный некластерный. Это раз. Второе: индексы развешены на каждое их полей кластерного индекса, т.е. треть кластерного индекса в них уже присутствует. По месту не будет особой экономии, а вот запрос, который сейчас использует кластерный индекс, может свалится в скан по новому некластерному взамен ключа, бо там нет цены. Это было три.


1. Не понял, зачем ещё лепить констрант по 3-м полям?
2. Экономия будет заметная. С худшего случая, когда некластерный на Article имеем выигрыш в 8 + 18 - 4 = 22 байта на каждую запись. Итого около 5 ГБ.
3. Не вижу смысла городить новый некластерный.

4. Если кластерный будет на автоинкременте, то с учетом того, что записи не меняются, можно выставить филфактор на 100, вот ещё 10% среза с таблицы.
6 май 13, 14:10    [14262860]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Glory
Member

Откуда:
Сообщений: 104751
ROLpogo
2. Экономия будет заметная. С худшего случая, когда некластерный на Article имеем выигрыш в 8 + 18 - 4 = 22 байта на каждую запись. Итого около 5 ГБ.

В том то и вопрос - а зачем для приведенного примера запроса более одного индекса вообще ?
6 май 13, 14:24    [14262956]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
ROLpogo
Member

Откуда: Реутов
Сообщений: 219
Glory
ROLpogo
2. Экономия будет заметная. С худшего случая, когда некластерный на Article имеем выигрыш в 8 + 18 - 4 = 22 байта на каждую запись. Итого около 5 ГБ.

В том то и вопрос - а зачем для приведенного примера запроса более одного индекса вообще ?


Так автор же решает задачу уменьшения размера, занимаемого таблицей. А то, что появятся лукапы на кластерный после поиска по некластерным, думаю, не шибко скажется на скорости запросов, учитывая уменьшения самих индексов.
6 май 13, 14:46    [14263113]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
ROLpogo
1. Не понял, зачем ещё лепить констрант по 3-м полям?
Потому что там primary key constraint, а не просто индекс. Уникальность предполагается обеспечивать святым духом?
6 май 13, 14:47    [14263125]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
eny
Member

Откуда: москва
Сообщений: 292
Сергей Викт.,

Как я прочел намедни в доке по ms sql для продвинутых чайников, кластерный индекс это единственный индекс работающий с таблицей как со списком указателей на записи.

Кроме того, кластерный индекс уже содержит все поля таблицы входящие в индекс (те часть таблицы). Таким образом настоящий размер таблицы равен равен кластерный индекс + все остальные страницы с не индексируемыми полями.

Так вот, при оптимизации запросов с кластерным индексом самая засада, потому что остальные, не кластерные индексы, указывают не на записи таблицы как таковые, а на запись в кластерном индексе! Соответственно, именно на больших и средних объемах данных, от отдельных индексов по столбцам кластерного индекса толку - ноль и оптимизатор MS SQL НИКОГДА не будет их использовать. Потому-что поиск по любому не кластерному индексу сводится к получению позиции кластерного индекса.

Имеет смысл забить на кластер - то есть сделать первичный индекс не кластерным, этим поимеем какое-то уменьшение суммарного размера, сама таблица распухнет за счет индексных полей из кластера и все индексы станут как индексы, то есть будут указывать на строки таблицы и использоваться оптимизатором.
6 май 13, 14:48    [14263136]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
ROLpogo
Так автор же решает задачу уменьшения размера, занимаемого таблицей. А то, что появятся лукапы на кластерный после поиска по некластерным, думаю, не шибко скажется на скорости запросов, учитывая уменьшения самих индексов.
Ну сделайте 100к лукапов на запрос, очень удивитесь, насколько.
6 май 13, 14:49    [14263146]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
eny
Member

Откуда: москва
Сообщений: 292
eny
Сергей Викт.,

Как я прочел намедни в доке по ms sql для продвинутых чайников, кластерный индекс это единственный индекс работающий с таблицей как со списком указателей на записи.



становиться таковым при создании

весь профит от кластерного индекса - оптимизация выполнения order by и group by по соответсвующим полям.

Кроме того, следует самое селективное поле ставить в индексе первым, скорее всего поле даты не самое селективное лучше посмотреть на другие поля если я не ошибаюсь
6 май 13, 14:53    [14263178]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
eny
Соответственно, именно на больших и средних объемах данных, от отдельных индексов по столбцам кластерного индекса толку - ноль и оптимизатор MS SQL НИКОГДА не будет их использовать. Потому-что поиск по любому не кластерному индексу сводится к получению позиции кластерного индекса.


Плохо читали. Читайте еще раз.

if object_id('tempdb..#t') is not null
    drop table #t
    
create table #t (
    a1      int not null
    , a2    int not null
    , a3    int not null
    
) 

create clustered index #t_clustered on #t ( a1, a2, a3 )
create index #t_a2 on #t ( a2 )
create index #t_a3 on #t ( a3 )

insert #t (
    a1
    , a2
    , a3
)
select
    1
    , 1
    , 1
    

set statistics profile on 
select * from #t where a1 = 1    
select * from #t where a2 = 1    
select * from #t where a3 = 1    
set statistics profile off


(1 row(s) affected)
a1          a2          a3
----------- ----------- -----------
1           1           1

(1 row(s) affected)

Rows                 Executes             StmtText                                                                                                      StmtId      NodeId      Parent      PhysicalOp                     LogicalOp                      Argument                                                                           DefinedValues                                                                 EstimateRows  EstimateIO    EstimateCPU   AvgRowSize  TotalSubtreeCost OutputList                                                                    Warnings Type                                                             Parallel EstimateExecutions
-------------------- -------------------- ------------------------------------------------------------------------------------------------------------- ----------- ----------- ----------- ------------------------------ ------------------------------ ---------------------------------------------------------------------------------- ----------------------------------------------------------------------------- ------------- ------------- ------------- ----------- ---------------- ----------------------------------------------------------------------------- -------- ---------------------------------------------------------------- -------- ------------------
1                    1                    select * from #t where a1 = 1                                                                                 1           1           0           NULL                           NULL                           NULL                                                                               NULL                                                                          1             NULL          NULL          NULL        0,0032831        NULL                                                                          NULL     SELECT                                                           0        NULL
1                    1                      |--Clustered Index Seek(OBJECT:([tempdb].[dbo].[#t]), SEEK:([tempdb].[dbo].[#t].[a1]=(1)) ORDERED FORWARD)  1           2           1           Clustered Index Seek           Clustered Index Seek           OBJECT:([tempdb].[dbo].[#t]), SEEK:([tempdb].[dbo].[#t].[a1]=(1)) ORDERED FORWARD  [tempdb].[dbo].[#t].[a1], [tempdb].[dbo].[#t].[a2], [tempdb].[dbo].[#t].[a3]  1             0,003125      0,0001581     19          0,0032831        [tempdb].[dbo].[#t].[a1], [tempdb].[dbo].[#t].[a2], [tempdb].[dbo].[#t].[a3]  NULL     PLAN_ROW                                                         0        1

(2 row(s) affected)

a1          a2          a3
----------- ----------- -----------
1           1           1

(1 row(s) affected)

Rows                 Executes             StmtText                                                                                            StmtId      NodeId      Parent      PhysicalOp                     LogicalOp                      Argument                                                                           DefinedValues                                                                 EstimateRows  EstimateIO    EstimateCPU   AvgRowSize  TotalSubtreeCost OutputList                                                                    Warnings Type                                                             Parallel EstimateExecutions
-------------------- -------------------- --------------------------------------------------------------------------------------------------- ----------- ----------- ----------- ------------------------------ ------------------------------ ---------------------------------------------------------------------------------- ----------------------------------------------------------------------------- ------------- ------------- ------------- ----------- ---------------- ----------------------------------------------------------------------------- -------- ---------------------------------------------------------------- -------- ------------------
1                    1                    select * from #t where a2 = 1                                                                       2           1           0           NULL                           NULL                           NULL                                                                               NULL                                                                          1             NULL          NULL          NULL        0,0032831        NULL                                                                          NULL     SELECT                                                           0        NULL
1                    1                      |--Index Seek(OBJECT:([tempdb].[dbo].[#t]), SEEK:([tempdb].[dbo].[#t].[a2]=(1)) ORDERED FORWARD)  2           2           1           Index Seek                     Index Seek                     OBJECT:([tempdb].[dbo].[#t]), SEEK:([tempdb].[dbo].[#t].[a2]=(1)) ORDERED FORWARD  [tempdb].[dbo].[#t].[a1], [tempdb].[dbo].[#t].[a2], [tempdb].[dbo].[#t].[a3]  1             0,003125      0,0001581     19          0,0032831        [tempdb].[dbo].[#t].[a1], [tempdb].[dbo].[#t].[a2], [tempdb].[dbo].[#t].[a3]  NULL     PLAN_ROW                                                         0        1

(2 row(s) affected)

a1          a2          a3
----------- ----------- -----------
1           1           1

(1 row(s) affected)

Rows                 Executes             StmtText                                                                                            StmtId      NodeId      Parent      PhysicalOp                     LogicalOp                      Argument                                                                           DefinedValues                                                                 EstimateRows  EstimateIO    EstimateCPU   AvgRowSize  TotalSubtreeCost OutputList                                                                    Warnings Type                                                             Parallel EstimateExecutions
-------------------- -------------------- --------------------------------------------------------------------------------------------------- ----------- ----------- ----------- ------------------------------ ------------------------------ ---------------------------------------------------------------------------------- ----------------------------------------------------------------------------- ------------- ------------- ------------- ----------- ---------------- ----------------------------------------------------------------------------- -------- ---------------------------------------------------------------- -------- ------------------
1                    1                    select * from #t where a3 = 1                                                                       3           1           0           NULL                           NULL                           NULL                                                                               NULL                                                                          1             NULL          NULL          NULL        0,0032831        NULL                                                                          NULL     SELECT                                                           0        NULL
1                    1                      |--Index Seek(OBJECT:([tempdb].[dbo].[#t]), SEEK:([tempdb].[dbo].[#t].[a3]=(1)) ORDERED FORWARD)  3           2           1           Index Seek                     Index Seek                     OBJECT:([tempdb].[dbo].[#t]), SEEK:([tempdb].[dbo].[#t].[a3]=(1)) ORDERED FORWARD  [tempdb].[dbo].[#t].[a1], [tempdb].[dbo].[#t].[a2], [tempdb].[dbo].[#t].[a3]  1             0,003125      0,0001581     19          0,0032831        [tempdb].[dbo].[#t].[a1], [tempdb].[dbo].[#t].[a2], [tempdb].[dbo].[#t].[a3]  NULL     PLAN_ROW                                                         0        1

(2 row(s) affected)
6 май 13, 14:59    [14263226]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Сергей Викт.
Member

Откуда: Москва
Сообщений: 888
eny
Кроме того, следует самое селективное поле ставить в индексе первым, скорее всего поле даты не самое селективное лучше посмотреть на другие поля если я не ошибаюсь


Вот сайчас отлавливаю статистику. 50 на 50) Type и Date) Но вроде Type более селективен
6 май 13, 15:00    [14263239]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
eny
весь профит от кластерного индекса - оптимизация выполнения order by и group by по соответсвующим полям.
Типа некластерный для выполнения order by и group by использоваться не может что ли?

eny
Кроме того, следует самое селективное поле ставить в индексе первым, скорее всего поле даты не самое селективное лучше посмотреть на другие поля если я не ошибаюсь
Вы та еще ванга, судить по селективности без данных. Давайте еще расскажите, что на поле bit нельзя делать индекс, и сервер никогда не будет его использовать, там же всего три значения может быть.
6 май 13, 15:03    [14263260]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
eny
Member

Откуда: москва
Сообщений: 292
Гавриленко Сергей Алексеевич
eny
Соответственно, именно на больших и средних объемах данных, от отдельных индексов по столбцам кластерного индекса толку - ноль и оптимизатор MS SQL НИКОГДА не будет их использовать. Потому-что поиск по любому не кластерному индексу сводится к получению позиции кластерного индекса.


Плохо читали. Читайте еще раз.



это вы плохо читали ;) я говорю про БОЛЬШИЕ ОБЪЕМЫ данных, пока таблицы маленькие MS SQL может искать по простому индексу, получать ссылку на кластерный индекс и искать но нему повторно, при этом сервер молчит как партизан, что ищет по кластеру во второй проход.

А вот на больших объемах сервер ищет ТУПО по кластеру всегда!
6 май 13, 15:06    [14263281]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
eny
Имеет смысл забить на кластер - то есть сделать первичный индекс не кластерным, этим поимеем какое-то уменьшение суммарного размера, сама таблица распухнет за счет индексных полей из кластера и все индексы станут как индексы, то есть будут указывать на строки таблицы и использоваться оптимизатором.
Типа операция RID Lookup бесплатная и не надо лезть по указанному физическому адресу, читать страницу а с нее - данные. А уже молчу про то, как классно ребилдить хипы.
6 май 13, 15:08    [14263301]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
eny
Так вот, при оптимизации запросов с кластерным индексом самая засада, потому что остальные, не кластерные индексы, указывают не на записи таблицы как таковые, а на запись в кластерном индексе! Соответственно, именно на больших и средних объемах данных, от отдельных индексов по столбцам кластерного индекса толку - ноль и оптимизатор MS SQL НИКОГДА не будет их использовать. Потому-что поиск по любому не кластерному индексу сводится к получению позиции кластерного индекса.
Первое и последнее предложение правильное, но вывод в среднем предложении неверный.

Поиск идеально делать по кластерному индексу, если условия поиска совпадают с полями кластерного индекса.
А если не совпадают, то получится скан кластерного индекса, то есть другими словами, скан таблицы (это синонимы).

Например, для случая ТС:
CREATE TABLE [dbo].[t_Pricelists]
(
  [PLDate] [datetime] NOT NULL,
  [PLType] [char](18) NOT NULL,
  [Article] [char](25) NOT NULL,
  [BPrice] [money] NOT NULL,
  CONSTRAINT [PK_Pricelists] PRIMARY KEY CLUSTERED 
  (
   [PLDate] ASC,
   [PLType] ASC,
   [Article] ASC
  )
)
Делаем условия выборки:
WHERE [Article] = 'asdf'

В этом случае будет сканится вся таблица, эффективность нулевая, будет прочитано и распарсено все 250 мегабайт.

Допустим, есть индекс на [Article]

Тогда сервер по этому индексу считает список ключей записей, найдёт их в кластерном индексе и получит страницы данных. Если селективность выборки по [Article] высокая (или указан TOP <небольшое число>), то будет прочитано не 250 мегабайт, а десятки килобайт (несколько страниц).

И чем больше таблица, тем это эффективнее.
6 май 13, 15:09    [14263310]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
eny
Member

Откуда: москва
Сообщений: 292
Гавриленко Сергей Алексеевич
eny
весь профит от кластерного индекса - оптимизация выполнения order by и group by по соответсвующим полям.
Типа некластерный для выполнения order by и group by использоваться не может что ли?

eny
Кроме того, следует самое селективное поле ставить в индексе первым, скорее всего поле даты не самое селективное лучше посмотреть на другие поля если я не ошибаюсь
Вы та еще ванга, судить по селективности без данных. Давайте еще расскажите, что на поле bit нельзя делать индекс, и сервер никогда не будет его использовать, там же всего три значения может быть.


Если все нужные записи для критерия group by и order by собраны в соседних страницах, то производительность алгоритмов сортировки и группировки повышается, это условие как-раз обеспечивает кластерный индекс. Обычные индексы такого свойства в общем случае не имеют.

А селективность очень важна. При чем здесь bit если в вышеприведенном индексе используются datetime и char?
6 май 13, 15:10    [14263316]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
eny
Гавриленко Сергей Алексеевич
пропущено...


Плохо читали. Читайте еще раз.



это вы плохо читали ;) я говорю про БОЛЬШИЕ ОБЪЕМЫ данных, пока таблицы маленькие MS SQL может искать по простому индексу, получать ссылку на кластерный индекс и искать но нему повторно, при этом сервер молчит как партизан, что ищет по кластеру во второй проход.

А вот на больших объемах сервер ищет ТУПО по кластеру всегда!
Вас же не затруднит подтвердить ваши слова примером. Потому что вы говорите полную чушь.
6 май 13, 15:11    [14263328]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31912
eny
это вы плохо читали ;) я говорю про БОЛЬШИЕ ОБЪЕМЫ данных, пока таблицы маленькие MS SQL может искать по простому индексу, получать ссылку на кластерный индекс и искать но нему повторно, при этом сервер молчит как партизан, что ищет по кластеру во второй проход.
Сервер всегда после поиска по индексу будет делать второй поиск на страничный уровень, либо по кластерному индексу, либо по ИД страницы, это одно и то же (исключая случай, когда все данные есть в индексе).

Как же иначе, без второго прохода???
6 май 13, 15:12    [14263337]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
eny
Member

Откуда: москва
Сообщений: 292
alexeyvg
найдёт их в кластерном индексе и получит страницы данных


А как по-вашему происходит поиск в кластерном индексе? С помощью этого самого индекса, а индекс заточен первым измерением не на [Article] а на [PLDate] и ага - никакой кластеризации в помине.

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

Строить отдельные индексы по вторым, третьим и прочим измерениям кластера бессмысленно. Потому-что кластер по-определению "упорядочен" по этим измерениям случайным образом
6 май 13, 15:19    [14263394]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
set statistics profile on 
select
    *
from    dbo.SomeBigTable  a
where
    a.binary_key = 0x00000000000000000000000000004440


select
    *
from    dbo.SomeBigTable  a
where
    a.bigint_key = 1549570828

set statistics profile off

bigint_key            binary_key                        insert_time             another_field
-------------------- ---------------------------------- ----------------------- --------------------
1549570828           0x00000000000000000000000000004440 2012-11-22 15:45:00     24323270

(1 row(s) affected)

Rows                 Executes             StmtText                                                                                                                                                     StmtId      NodeId      Parent      PhysicalOp                     LogicalOp                      Argument                                                                                                                                    DefinedValues                                                            EstimateRows  EstimateIO    EstimateCPU   AvgRowSize  TotalSubtreeCost OutputList                                                               Warnings Type                                                             Parallel EstimateExecutions
-------------------- -------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------ ----------- ----------- ----------- ------------------------------ ------------------------------ ------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------ ------------- ------------- ------------- ----------- ---------------- ------------------------------------------------------------------------ -------- ---------------------------------------------------------------- -------- ------------------
1                    1                    SELECT * FROM [dbo].[SomeBigTable] [a] WHERE [a].[binary_key]=@1                                                                                              1           1           0           NULL                           NULL                           NULL                                                                                                                                        NULL                                                                     1,104351      NULL          NULL          NULL        0,003283215      NULL                                                                     NULL     SELECT                                                           0        NULL
1                    1                      |--Index Seek(OBJECT:([SomeBigDataBase].[dbo].[SomeBigTable].[IX__SomeBigTable__binary_key__insert_time] AS [a]), SEEK:([a].[binary_key]=[@1]) ORDERED FORWARD)  1           2           1           Index Seek                     Index Seek                     OBJECT:([SomeBigDataBase].[dbo].[SomeBigTable].[IX__SomeBigTable__binary_key__insert_time] AS [a]), SEEK:([a].[binary_key]=[@1]) ORDERED FORWARD  [a].[bigint_key], [a].[binary_key], [a].[insert_time], [a].[another_field]  1,104351      0,003125      0,0001582148  43          0,003283215      [a].[bigint_key], [a].[binary_key], [a].[insert_time], [a].[another_field]  NULL     PLAN_ROW                                                         0        1

(2 row(s) affected)

bigint_key            binary_key                        insert_time             another_field
-------------------- ---------------------------------- ----------------------- --------------------
1549570828           0x00000000000000000000000000004440 2012-11-22 15:45:00     24323270

(1 row(s) affected)

Rows                 Executes             StmtText                                                                                                                                                                         StmtId      NodeId      Parent      PhysicalOp                     LogicalOp                      Argument                                                                                                                                              DefinedValues                                                            EstimateRows  EstimateIO    EstimateCPU   AvgRowSize  TotalSubtreeCost OutputList                                                               Warnings Type                                                             Parallel EstimateExecutions
-------------------- -------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------- ----------- ----------- ------------------------------ ------------------------------ ----------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------ ------------- ------------- ------------- ----------- ---------------- ------------------------------------------------------------------------ -------- ---------------------------------------------------------------- -------- ------------------
1                    1                    SELECT * FROM [dbo].[SomeBigTable] [a] WHERE [a].[bigint_key]=@1                                                                                                                    2           1           0           NULL                           NULL                           NULL                                                                                                                                                  NULL                                                                     1,481706      NULL          NULL          NULL        0,00328363       NULL                                                                     NULL     SELECT                                                           0        NULL
1                    1                      |--Clustered Index Seek(OBJECT:([SomeBigDataBase].[dbo].[SomeBigTable].[IX__SomeBigTable__clustered] AS [a]), SEEK:([a].[bigint_key]=CONVERT_IMPLICIT(bigint,[@1],0)) ORDERED FORWARD)  2           2           1           Clustered Index Seek           Clustered Index Seek           OBJECT:([SomeBigDataBase].[dbo].[SomeBigTable].[IX__SomeBigTable__clustered] AS [a]), SEEK:([a].[bigint_key]=CONVERT_IMPLICIT(bigint,[@1],0)) ORDERED FORWARD  [a].[bigint_key], [a].[binary_key], [a].[insert_time], [a].[another_field]  1,481706      0,003125      0,0001586299  43          0,00328363       [a].[bigint_key], [a].[binary_key], [a].[insert_time], [a].[another_field]  NULL     PLAN_ROW                                                         0        1

(2 row(s) affected)


Таблица:
name                                                                                                                             rows        reserved           data               index_size         unused
-------------------------------------------------------------------------------------------------------------------------------- ----------- ------------------ ------------------ ------------------ ------------------
SomeBigTable                                                                                                                     1668990048  225184512 KB       59688416 KB        164629040 KB       867056 KB


Кластерный по (bigint_key, binary_key), некластерный по binary_key.

Так же будем считать, что таблица под определение "большие данные" подходит.

Сообщение было отредактировано: 6 май 13, 15:22
6 май 13, 15:19    [14263398]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
eny
Строить отдельные индексы по вторым, третьим и прочим измерениям кластера бессмысленно. Потому-что кластер по-определению "упорядочен" по этим измерениям случайным образом
Вы порете просто удивительную чушь.
6 май 13, 15:21    [14263412]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
eny
Member

Откуда: москва
Сообщений: 292
Гавриленко Сергей Алексеевич,

ага без проблем:
Хендерсон - Профессиональное руководство по MS SQL server
Дэн Тоу - Настройка SQL для профессионалов

можно стянуть с торрентов
6 май 13, 15:22    [14263421]     Ответить | Цитировать Сообщить модератору
 Re: Господа, прошу помощи с оптимизацией индексной структуры  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
eny
Гавриленко Сергей Алексеевич,

ага без проблем:
Хендерсон - Профессиональное руководство по MS SQL server
Дэн Тоу - Настройка SQL для профессионалов

можно стянуть с торрентов
Там этой чуши нет. Вас же не затруднит дать цитату из книги?
6 май 13, 15:24    [14263437]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить