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

Откуда:
Сообщений: 104751
То, что вы цитируете, называется Bookmark lookup
Т.е. операция, при которой сервер обращается за данными собственно к записям таблицы
Потому что в индексе просто напросто нет этих данных
И о том, выгодно это будет или не выгодно, сервер решает на этапе создания плана выполнения
27 окт 10, 17:06    [9686780]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Quest123
Guest
Glory
То, что вы цитируете, называется Bookmark lookup
Т.е. операция, при которой сервер обращается за данными собственно к записям таблицы
Потому что в индексе просто напросто нет этих данных
И о том, выгодно это будет или не выгодно, сервер решает на этапе создания плана выполнения
А разве в НИ данные находятся в индексе?
27 окт 10, 17:10    [9686826]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Glory
Member

Откуда:
Сообщений: 104751
Quest123
Glory
То, что вы цитируете, называется Bookmark lookup
Т.е. операция, при которой сервер обращается за данными собственно к записям таблицы
Потому что в индексе просто напросто нет этих данных
И о том, выгодно это будет или не выгодно, сервер решает на этапе создания плана выполнения
А разве в НИ данные находятся в индексе?

А разве в индексе всегда находятся все данные, которые нужны в запросе
вот при select * from mytable where indexedfield=1 откуда возьмутся значения select * ?
27 окт 10, 17:12    [9686842]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Quest123
Guest
Glory
А разве в индексе всегда находятся все данные, которые нужны в запросе
вот при select * from mytable where indexedfield=1 откуда возьмутся значения select * ?

Так я про это же!
Непонятно, причем тут Bookmark lookup и заданный мною вопрос?
27 окт 10, 17:16    [9686888]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Glory
Member

Откуда:
Сообщений: 104751
Quest123
Glory
А разве в индексе всегда находятся все данные, которые нужны в запросе
вот при select * from mytable where indexedfield=1 откуда возьмутся значения select * ?

Так я про это же!

Про что про это ?
Если indexedfield с хорошей селективностью, то выгоднее найти по индексу значение кластерного ключа или rid-а и потому считать остальные поля из таблицы
И совершенно без разницы будет это именно кластерный индекс или rid
27 окт 10, 17:19    [9686923]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Quest123
Почему на кластеризованной таблице для некластеризованных индексов на листовом уровне хранить не кластеризованный ключ, а RID ?
Например, чтобы перемещение ключа кластерного индекса (при ребилде, апдейте, и, особенно, расщеплении страницы) не превратилось в адский ад: на каждый переместившийся ключ (вместе с данными) кластерного индекса надо делать поиск по соответствующему некластерному и менять там RID.

Сообщение было отредактировано: 27 окт 10, 17:21
27 окт 10, 17:20    [9686937]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31964
Glory
Про что про это ?
Если indexedfield с хорошей селективностью, то выгоднее найти по индексу значение кластерного ключа или rid-а и потому считать остальные поля из таблицы
И совершенно без разницы будет это именно кластерный индекс или rid
ТС спрашивает про то, почему на листьях НИ не лежат сразу номера страниц. Ведь по значению кластерного ключа их ещё всё надо поискать (тоже по дереву индекса, уже на этот раз кластерного).

Мне тоже непонятно, почему МС так сделали, нигде про это не нашёл.
27 окт 10, 17:23    [9686972]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
alexeyvg
ТС спрашивает про то, почему на листьях НИ не лежат сразу номера страниц. Ведь по значению кластерного ключа их ещё всё надо поискать (тоже по дереву индекса, уже на этот раз кластерного).

Мне тоже непонятно, почему МС так сделали, нигде про это не нашёл.
Все поди размышляли на эту тему. ;) Свой вывод я написал постом выше.
27 окт 10, 17:24    [9686987]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Glory
Member

Откуда:
Сообщений: 104751
alexeyvg
Glory
Про что про это ?
Если indexedfield с хорошей селективностью, то выгоднее найти по индексу значение кластерного ключа или rid-а и потому считать остальные поля из таблицы
И совершенно без разницы будет это именно кластерный индекс или rid
ТС спрашивает про то, почему на листьях НИ не лежат сразу номера страниц. Ведь по значению кластерного ключа их ещё всё надо поискать (тоже по дереву индекса, уже на этот раз кластерного).

Мне тоже непонятно, почему МС так сделали, нигде про это не нашёл.

Наверное потому, что запись может переместится со страницы на страницу ?
27 окт 10, 17:27    [9687011]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Quest123
Guest
Glory
Quest123
Glory
А разве в индексе всегда находятся все данные, которые нужны в запросе
вот при select * from mytable where indexedfield=1 откуда возьмутся значения select * ?

Так я про это же!

Про что про это ?
Если indexedfield с хорошей селективностью, то выгоднее найти по индексу значение кластерного ключа или rid-а и потому считать остальные поля из таблицы
И совершенно без разницы будет это именно кластерный индекс или rid

Можете расшифровать вышесказанное Вами на следующем примере:
--Допустим, есть 2 таблицы:
-- 1-я с кластерным индексом
create table MyTable1
(
  id int identity(1,1) primary key clustered --кластерный индекс
 ,date1 datetime
 ,num int
 ,myName varchar(50)
)
go
-- 2-я без кластерного индекса
create table MyTable2
(
  id int identity(1,1) primary key nonclustered --не кластерный индекс
 ,date1 datetime
 ,num int
 ,myName varchar(50)
)
go
--НИ для MyTable1
create nonclustered index idx1 (date1,num) on MyTable1
go
--НИ для MyTable2
create nonclustered index idx2 (date1,num) on MyTable2
go
--Допустим, состав обеих таблиц одинаков: 100 000 записей 
--Запрос для MyTable1
select myName from MyTable1 where date1>='20091001' and date1<='20091031' and num=10
--Запрос для MyTable2
select myName from MyTable1 where date1>='20091001' and date1<='20091031' and num=10
Где скорость выполнения запроса будет выше?
Почему?
27 окт 10, 17:35    [9687103]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Quest123
Guest
alexeyvg
Glory
Про что про это ?
Если indexedfield с хорошей селективностью, то выгоднее найти по индексу значение кластерного ключа или rid-а и потому считать остальные поля из таблицы
И совершенно без разницы будет это именно кластерный индекс или rid
ТС спрашивает про то, почему на листьях НИ не лежат сразу номера страниц. Ведь по значению кластерного ключа их ещё всё надо поискать (тоже по дереву индекса, уже на этот раз кластерного).

Мне тоже непонятно, почему МС так сделали, нигде про это не нашёл.

Ну наконец-то кто-то понял мой вопрос!
27 окт 10, 17:36    [9687123]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Glory
Member

Откуда:
Сообщений: 104751
Quest123
[
Где скорость выполнения запроса будет выше?
Почему?

Посмотрите план выполнения и увидите, где и почему
Заодно и статистику чтений включите
27 окт 10, 17:37    [9687128]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Quest123
Guest
Гавриленко Сергей Алексеевич
Quest123
Почему на кластеризованной таблице для некластеризованных индексов на листовом уровне хранить не кластеризованный ключ, а RID ?
Например, чтобы перемещение ключа кластерного индекса (при ребилде, апдейте, и, особенно, расщеплении страницы) не превратилось в адский ад: на каждый переместившийся ключ (вместе с данными) кластерного индекса надо делать поиск по соответствующему некластерному и менять там RID.
А значение кластерного индекса на листе НИ в этом случае не надо искать и менять?
27 окт 10, 17:40    [9687166]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Quest123
Guest
Glory
Quest123
[
Где скорость выполнения запроса будет выше?
Почему?

Посмотрите план выполнения и увидите, где и почему
Заодно и статистику чтений включите

Просто я думал, что здешние Гуру сходу ответят, как это должно быть на самом деле...
27 окт 10, 17:43    [9687191]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Glory
Member

Откуда:
Сообщений: 104751
Quest123
Гавриленко Сергей Алексеевич
Quest123
Почему на кластеризованной таблице для некластеризованных индексов на листовом уровне хранить не кластеризованный ключ, а RID ?
Например, чтобы перемещение ключа кластерного индекса (при ребилде, апдейте, и, особенно, расщеплении страницы) не превратилось в адский ад: на каждый переместившийся ключ (вместе с данными) кластерного индекса надо делать поиск по соответствующему некластерному и менять там RID.
А значение кластерного индекса на листе НИ в этом случае не надо искать и менять?

Если оно не менялось, то зачем его менять ?
27 окт 10, 17:43    [9687201]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
alexeyvg
Member

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

Да, видимо для этого...

Quest123
А значение кластерного индекса на листе НИ в этом случае не надо искать и менять?
Если сам кластерный ключ не меняется, то конечно не надо.
27 окт 10, 17:44    [9687202]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Glory
Member

Откуда:
Сообщений: 104751
Quest123
Glory
Quest123
[
Где скорость выполнения запроса будет выше?
Почему?

Посмотрите план выполнения и увидите, где и почему
Заодно и статистику чтений включите

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

Вы путаете гуру с Кашпировскими и Чумаками
Они по фотографии умели лечить болезни
27 окт 10, 17:45    [9687216]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Quest123
Guest
Ok! Вроде более- менее стало понятно. Спасибо всем откликнувшимся!
27 окт 10, 17:58    [9687342]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Александр Третьяков
Member

Откуда: Украина, г. Тернополь
Сообщений: 549
SQL2005SP3
Пример кода, и результат об котором говорил автор топика
в зависимости от размера таблицы можно смотреть помогает или тормозит индекс и первичный ключ или нет.
+
--Допустим, есть 2 таблицы:
-- 1-я с кластерным индексом
create table MyTable1
(
  id int identity(1,1) primary key clustered --кластерный индекс
 ,date1 datetime
 ,num int
 ,myName varchar(50)
)
go
-- 2-я без кластерного индекса
create table MyTable2
(
  id int identity(1,1) primary key nonclustered --не кластерный индекс
 ,date1 datetime
 ,num int
 ,myName varchar(50)
)
go
-- 3-я без кластерного индекса и ключа
create table MyTable3
(
  id int identity(1,1) --не кластерный индекс и не ключ
 ,date1 datetime
 ,num int
 ,myName varchar(50)
)
go
--НИ для MyTable1
create nonclustered index idx1 on MyTable1 (date1,num)
go
--НИ для MyTable2
create nonclustered index idx2 on MyTable2 (date1,num)
go
create nonclustered index idx3 on MyTable3 (date1,num)
go

declare @i int
set @i=0
while (@i<10000000)
begin
	if @i=1000000
		set @i=0
	set @i=@i+1
	insert into MyTable1 (date1,num,myName)
	values (dateadd(ms,@i,getdate()),@i,str(@i))
end

set @i=0
while (@i<10000000)
begin
	if @i=1000000
		set @i=0
	set @i=@i+1
	insert into MyTable2 (date1,num,myName)
	values (dateadd(ms,@i,getdate()),@i,str(@i))
end

set @i=0
while (@i<10000000)
begin
	if @i=1000000
		set @i=0
	set @i=@i+1
	insert into MyTable3 (date1,num,myName)
	values (dateadd(ms,@i,getdate()),@i,str(@i))
end

GO
declare @daten datetime,@i int
set @daten=getdate()
set @i=3478
--Допустим, состав обеих таблиц одинаков: 100 000 записей 
--Запрос для MyTable1
select myName from MyTable1 where date1>='20110401' and date1<='20111020' and num=@i
select getdate()-@daten
set @daten=getdate()
--Запрос для MyTable2
select myName from MyTable2 where date1>='20110401' and date1<='20111020' and num=@i
select getdate()-@daten
--Запрос для MyTable3
set @daten=getdate()
select myName from MyTable3 where date1>='20110401' and date1<='20111020' and num=@i
select getdate()-@daten
GO
23 авг 11, 19:06    [11166951]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Гавриленко Сергей Алексеевич
Quest123
Почему на кластеризованной таблице для некластеризованных индексов на листовом уровне хранить не кластеризованный ключ, а RID ?
Например, чтобы перемещение ключа кластерного индекса (при ребилде, апдейте, и, особенно, расщеплении страницы) не превратилось в адский ад: на каждый переместившийся ключ (вместе с данными) кластерного индекса надо делать поиск по соответствующему некластерному и менять там RID.


При изменении RID никто не делает никаких поисков с обновлением по некластерным индексам. Когда данные перемещаются, то на их месте создается ссылка на новую страницу, что естественно увеличивает издержки на поиск, но очевидно значительно быстрее чем обновлять все индексы.
24 авг 11, 01:18    [11168520]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Mind
При изменении RID никто не делает никаких поисков с обновлением по некластерным индексам. Когда данные перемещаются, то на их месте создается ссылка на новую страницу, что естественно увеличивает издержки на поиск, но очевидно значительно быстрее чем обновлять все индексы.
Может и быстрее, только не понятно, как ими сервер после управляет. Как долго эти ссылки живут? Вечно? Как сервер понимает, что на ссылку уже никакой некластерный не ссылается (грохнули его, примеру, или ключ из фильтрованного индекса ушел, потому что перестал попадать под условия фильтрации) и ее надо удалить? Есть где почитать об этом?
24 авг 11, 09:41    [11168983]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Гавриленко Сергей Алексеевич
Может и быстрее, только не понятно, как ими сервер после управляет. Как долго эти ссылки живут? Вечно? Как сервер понимает, что на ссылку уже никакой некластерный не ссылается (грохнули его, примеру, или ключ из фильтрованного индекса ушел, потому что перестал попадать под условия фильтрации) и ее надо удалить? Есть где почитать об этом?


Если подумать логически, то для того чтобы избавится от этих ссылок, серверу нужно проделать весьма значительное количество работы, которое в фоновом режиме, по своему усмотрению, он явно сделать не сможет. Фактически нужно сделать полный REBUILD для кучи. Я лично могу придумать только 2 сценария: построение кластерного индекса (и потом прибивание оного при необходимости) или shrink file, при котором, в теории таблица должна быть физически перемещена на другие страницы с заменой всех RID. Учитывая, что и то другое весьма дорогостоящие операции, я бы сказал что эти ссылки будут жить "условно вечно".
Мне кажется что где-то я про это читал, если найду - скину.

С другой стороны, а чем мешают эти ссылки, если на них уже никто не ссылается? Если никто на них не ссылается, то ситуация обращения к ним в принципе невозможна и соответственно падения производительности не будет. А то, что этот фактически мусор, занимает немного места, так об этом, я думаю, тот кто создавал кучу должен был подумать заранее, ибо, если мне не изменяет память, с высвобождением пустых страниц у таблиц без кластерного индекса все весьма и весьма печально in general. И несколько лишних 8 байтовых поинтеров погоды не сделают.

Хотя, придумал еще один вариант - DELETE FROM table :)
24 авг 11, 20:38    [11173947]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Гавриленко Сергей Алексеевич
Есть где почитать об этом?


Вот собственно всё что есть по этой теме:
Microsoft SQL Server 2008 Internals
Managing Forward Pointers
Forward pointers allow you to modify data in a heap without worrying about having to make
drastic changes to the nonclustered indexes. If a row that has been forwarded must move again,
the original forwarding pointer is updated to point to the new location. You’ll never end up with
a forwarding pointer pointing to another forwarding pointer. In addition, if the forwarded row
shrinks enough to fi t in its original place, the record might move back to its original place (if
there is still room on that page), and the forward pointer would be eliminated.

A future version of SQL Server might include some mechanism for performing a physical
reorganization of the data in a heap, which would get rid of forward pointers. Note that
forward pointers exist only in heaps, and that the ALTER TABLE option to reorganize a table
won’t do anything to heaps. You can defragment a nonclustered index on a heap but not
the table itself. Currently, when a forward pointer is created, it stays there forever—with only
a few exceptions. The fi rst exception is the case I already mentioned, in which a row shrinks
and returns to its original location. The second exception is when the entire database shrinks.
The bookmarks are actually reassigned when a fi le is shrunk. The shrink process never
generates forwarding pointers. For pages that were removed because of the shrink process,
any forwarded rows or stubs they contain are effectively “unforwarded.” Other cases in which
the forwarding pointers are removed are the obvious ones: if the forwarded row is deleted,
or if a clustered index is built on the table so that it is no longer a heap.
25 авг 11, 07:38    [11175084]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Mind,

Спасибо.
25 авг 11, 11:13    [11176187]     Ответить | Цитировать Сообщить модератору
 Re: Некластеризованный индекс на кластеризованной таблице  [new]
Александр Третьяков
Member

Откуда: Украина, г. Тернополь
Сообщений: 549
Mind
я приводил код для того чтобы сравнить скорость выборки из таблицы с кластерным индексом и без него, а также с первичным ключом.
У кого какие результаты?
25 авг 11, 19:19    [11181037]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить