powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Некластерный индекс по полям кластерного. В чем фишка?
48 сообщений из 48, показаны все 2 страниц
Некластерный индекс по полям кластерного. В чем фишка?
    #40065423
godsql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Рассматриваю базу. Наткнулся на такой интересный прием.
На таблице могут висеть одновременно кластерный и некластерный индекс.
В чем преимущество данного метода перед "просто кластерным"? Или я чего-то не замечаю?

Скрипты прилагаю
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
ALTER TABLE [dbo].[T1] ADD  CONSTRAINT [PK__T1____] PRIMARY KEY CLUSTERED
(
       [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF,
ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [PK_T1] ON [dbo].[T1]
(
       [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF,
ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065429
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну... если основной запрос exists( select * from table where ID = @ID)
то это будут чуток бодрее.
Но надо поставить UNIQUE.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065434
godsql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ну, там вообще основной поиск ведется по другим полям, так что прибавка шустрости не гарантируется :)
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065436
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
godsql
ну, там вообще основной поиск ведется по другим полям, так что прибавка шустрости не гарантируется :)


тогда содержание некластерного индекса это - пустая трата свободного места.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065452
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
godsql,

Ну например, select count(*) from dbo.T1 with (index = PK_T1) будет а) значительно быстрее, если таблица широкая и б) не будет ждать завершения обновлений таблицы из других сеансов.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065464
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
godsql На таблице могут висеть одновременно кластерный и некластерный индекс.Я бы предположил Бритву Хэнлона
Скрипт для кластерного индекса генерировался роботом, а некластерного человеком.

Я бы на вашем месте прогнал скриптик по другим таблицам/индексам
https://www.sqlservercentral.com/articles/finding-and-eliminating-duplicate-or-overlapping-indexes-1
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065466
godsql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
в общем, понятно. Сильно специфичное использование.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065469
godsql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257
godsql На таблице могут висеть одновременно кластерный и некластерный индекс.
Я бы предположил Бритву Хэнлона
Скрипт для кластерного индекса генерировался роботом, а некластерного человеком.


Если я начну копаться основательно, то основную работу делать не смогу :) Там такой ужас, что кажется, что это студенты писали. Хотя стоит эта хрень - дофига. Правлю то, с чем работаю.

За статью спасибо, почитаю.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065490
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
godsql Если я начну копаться основательно, то основную работу делать не смогу :) Там такой ужас, что кажется, что это студенты писали. Хотя стоит эта хрень - дофига.это норма (с) Елена Малышева
Я бы предложил прогнать скриптик чтобы получить список подозрительных индексов (это быстро). Кстати не забывайте про INCLUDE поля.
Далее, некластерные индексы с идентичным набором полей (как в вашем случае) это абсолютное зло и кандидат на удаление.
Если боитесь удалять (запрещено вендором) - есть вариант с disable https://docs.microsoft.com/en-us/sql/relational-databases/indexes/disable-indexes-and-constraints?view=sql-server-ver15
Засада может быть только если имя индекса используется как подсказка в запросах (см пример от invm)

В случае частичного пересечения не все так однозначно.
Если будете копать, то посмотрите в сторону утилиты от Брента Озара
https://www.brentozar.com/blitzindex/
https://www.brentozar.com/blitzindex/sp_blitzindex-duplicate-indexes/
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065641
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
godsql,

Если есть запросы, которые выбирают только ID то м.б. профит от покрытия такого запроса некластерным индексом.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065650
Фотография SIMPLicity_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Возможно, что второй индекс (nonclustered) был изначально [ID] DEsc (а не [ID] ASC), и использовался для а) выборки последних Икс айдишников (select top 10 id from table (noock) order by id desc), б) для избегания блокировок при быстром сёрфинге по таблице (с тем же nolock-ом, например) ... Короткевич про что-то похожее, кстати, когда-то рассказывал. Но я точно не помню. Извините, есличо ;)
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065653
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SIMPLicity_ был изначально [ID] DEsc (а не [ID] ASC), и использовался для а) выборки последних Икс айдишников (select top 10 id from table (noock) order by id desc),А вот с этого места поподробнее.
Я всю жизнь был уверен что сервер прекрасно умеет ASC индекс для desc запросов.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065672
godsql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ради эксперимента сделал запросы
Select top 200000 * from table order by id asc
Select top 200000 * from table order by id desc

Везде используется Скан кластерного индекса (Отсортировано = true)
время выборки приблизительно одинаковое, причем desc - выигрывает и по количеству логических чтений (3785 против 4266), так и по затраченному времени
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065698
godsql
Ради эксперимента сделал запросы
Select top 200000 * from table order by id asc
Select top 200000 * from table order by id desc

Везде используется Скан кластерного индекса (Отсортировано = true)
время выборки приблизительно одинаковое, причем desc - выигрывает и по количеству логических чтений (3785 против 4266), так и по затраченному времени
На каждой странице может быть разное количество записей. Это связано как с тем, что записи могут иметь разный размер, так и с тем, что записи могут обновляться/удаляться. Это объясняет разницу в количестве прочитанных страниц.

Кластерный индекс - это и есть вся таблица. А в топике речь о не кластерном индексе. В нём не хранится ничего, кроме ID. Потому и места на диске он займёт сильно меньше. Соответственно, запросы вида SELECT COINT(*) FROM table, или SELECT TOP 1 ID FROM table ORDER BY ID DESC, или EXISTS(SELECT * FROM table WHERE ID = @ID) будут обращаться только к этом индексу и потребуют на порядки меньше операций чтения страниц.

Попробуйте вот эти запросы.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065699
aleks222
Ну... если основной запрос exists( select * from table where ID = @ID)
то это будут чуток бодрее.
Но надо поставить UNIQUE.
А индексы по первичному ключу не подразумевают автоматически UNIQUE? Оптимизатор сам не догадывается?
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065765
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257
SIMPLicity_ был изначально [ID] DEsc (а не [ID] ASC), и использовался для а) выборки последних Икс айдишников (select top 10 id from table (noock) order by id desc),
А вот с этого места поподробнее.
Я всю жизнь был уверен что сервер прекрасно умеет ASC индекс для desc запросов.Умеет, не вопрос. Проблема в том, что почему-то в MSSQL не реализован параллелизм для таких запросов.

Desc поиск по asc индексу всегда будет однопоточным.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40065774
aleks222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ведущий профессионал
aleks222
Ну... если основной запрос exists( select * from table where ID = @ID)
то это будут чуток бодрее.
Но надо поставить UNIQUE.
А индексы по первичному ключу не подразумевают автоматически UNIQUE? Оптимизатор сам не догадывается?

Чтению обучают в первом классе.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40066154
Фотография SIMPLicity_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрипт на существующий кластерный индекс и создание нового, идентичного но НЕкластерного, с обратной сортировкой

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SET ANSI_PADDING ON
GO

/****** Object:  Index [PK__Document__0476BE1F3B23C0D3]    Script Date: 26.04.2021 22:10:40 ******/
ALTER TABLE [dbo].[Documents_History] ADD PRIMARY KEY CLUSTERED 
(
	[posting_number] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
GO

create nonclustered index [Documents_History_idx] on [Documents_History] ([posting_number] deSC);



Вероятно есть какие-то причины использования НЕкластерного индекса. Запрос отработал (почему-то) вот так:
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40066157
Фотография SIMPLicity_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SIMPLicity_
Скрипт на существующий кластерный индекс и создание нового, ....


И да, MSSQL 2019, живая система,- да простят меня все за мои эксперименты на продакшне,- в таблице чуть менее 130 тыс строк. Ресурсов в достатке. особенно ночью ;) ...

PS Необычно ещё и то, что поле является единственным полем класт. первичного ключа - PRIMARY KEY CLUSTERED ( [posting_number] ASC ) - но первичный ключ использован не был (на скрине фактический план) .

Возможно MSSQL стал настолько умён, что для м**ацких запросов старается избегать блокировок ресурсов (в данном случае - всей таблицы ибо сканится кластерный индекс).

PS Есличо - могу ошибаться - готов выслушать критику....
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40066161
Фотография SIMPLicity_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
godsql
Ради эксперимента сделал запросы
Select top 200000 * from table order by id asc
Select top 200000 * from table order by id desc

Везде используется Скан кластерного индекса (Отсортировано = true)
время выборки приблизительно одинаковое, причем desc - выигрывает и по количеству логических чтений (3785 против 4266), так и по затраченному времени


Коллега, у Вас оба индекса ASC. А то что второй был изначально DESC ,- это было всего лишь МОЁ ПРЕДПОЛОЖЕНИЕ,- не более...
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40066201
SIMPLicity_
SIMPLicity_
Скрипт на существующий кластерный индекс и создание нового, ....


И да, MSSQL 2019, живая система,- да простят меня все за мои эксперименты на продакшне,- в таблице чуть менее 130 тыс строк. Ресурсов в достатке. особенно ночью ;) ...

PS Необычно ещё и то, что поле является единственным полем класт. первичного ключа - PRIMARY KEY CLUSTERED ( [posting_number] ASC ) - но первичный ключ использован не был (на скрине фактический план) .

Возможно MSSQL стал настолько умён, что для м**ацких запросов старается избегать блокировок ресурсов (в данном случае - всей таблицы ибо сканится кластерный индекс).

PS Есличо - могу ошибаться - готов выслушать критику....
Я уже писал, что дело в размерах. Просто посмотрите, сколько страниц занимает кластерный индекс, и сколько не кластерный.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40066357
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
godsql
в общем, понятно. Сильно специфичное использование.


Я бы сказал, что с вероятность 99% - это чьи-то кривые руки, возможно, после задачи типа "сделай индексы на все ID-поля".
Рекорд, который я встречал, это кластерный + 4 идентичных ему некластерных на немаленькой таблице )
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40066402
Фотография StarikNavy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик,

а вот здесь что лишнее? :)


ALTER TABLE [dbo].[tbl_Primer] ADD CONSTRAINT [PK8reomM] PRIMARY KEY NONCLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO


CREATE UNIQUE CLUSTERED INDEX [ClustPrimaKeyIx] ON [dbo].[tbl_Primer]
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
GO
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40066439
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Помнится, старые версии PowerDesigner так делали, если сразу не запретить. Там для MSSQL в дефолтных настройках было что-то типа "создавать индекс на каждый PK и UQ".
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40066468
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StarikNavy
Критик,

а вот здесь что лишнее? :)


ALTER TABLE [dbo].[tbl_Primer] ADD CONSTRAINT [PK8reomM] PRIMARY KEY NONCLUSTERED
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO


CREATE UNIQUE CLUSTERED INDEX [ClustPrimaKeyIx] ON [dbo].[tbl_Primer]
(
[Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
GO

у меня подобные 2 индекса, ПК и уникальный,
один кластерный, другой некластерный, на широченной таблице.
некластерный, разумеется, гораздо меньше весит,
лично мне надо для проверки ФК, ибо на эту таблицу смотрит туча других.
вот статистика по чтениям, сервер еще как обрадовался новому некластерному и юзает его,
хотя сделан не так давно:
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40066470
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
да, пардон, первая колонка sum_ss это user_seeks + user_scans
из sys.dm_db_index_usage_stats
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072437
Кесарь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yasha123

у меня подобные 2 индекса, ПК и уникальный,
один кластерный, другой некластерный, на широченной таблице.
некластерный, разумеется, гораздо меньше весит,
лично мне надо для проверки ФК, ибо на эту таблицу смотрит туча других.
вот статистика по чтениям, сервер еще как обрадовался новому некластерному и юзает его,
хотя сделан не так давно:


А не могли бы вы написать список полей обоих индексов для понимания? А то что-то я не догоняю, в чём смысл. Было бы интересно понять это решение.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072573
godsql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Кесарь
Yasha123

у меня подобные 2 индекса, ПК и уникальный,
один кластерный, другой некластерный, на широченной таблице.
некластерный, разумеется, гораздо меньше весит,
лично мне надо для проверки ФК, ибо на эту таблицу смотрит туча других.
вот статистика по чтениям, сервер еще как обрадовался новому некластерному и юзает его,
хотя сделан не так давно:


А не могли бы вы написать список полей обоих индексов для понимания? А то что-то я не догоняю, в чём смысл. Было бы интересно понять это решение.


Насколько я понял:
если индекс используется для выборки нескольких/многих/всех полей из этой же таблицы - используется кластерный индекс.
Если индекс используется только как ссылочный элемент/малая выборка - используется некластерный индекс
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072631
Фотография Александр Гладченко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это, увы, очень часто встречающаяся ситуация :(
Кластерный индекс по IDENTITY да ещё и первичный ключ - это вершина безграмотности дизайнера таблицы :) Вспомните труды одного славного парня, который таких горемык называл айдиотами
Кластерный индекс хорош при просмотрах полных и не полных, и когда нужно выдать много колонок.
Некластерный индек как раз для поиска хорошо работает, и первичный ключ по некластерному тут будет оптимизатору завсегда удобней.
То, что встречаются такие "сладкие" парочки с дублем колонок кластерного индекса - это компромис, чтобы малой кровью исправить чью то глупость.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072635
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гладченко
Кластерный индекс по IDENTITY да ещё и первичный ключ - это вершина безграмотности дизайнера таблицы


Вы же взрослый, опытный человек, а так безапелляционный несете чушь.


Я сходу назову две ситуации, при которых "кластерный индекс по IDENTITY да ещё и первичный ключ" лучший (если не единственный вариант)

1. Таблица а-ля очередь, к которой все запросы имею вид select top N ... from ... where id > @id order by id
2. Таблица, к которой все (ну или основная масса) запросы идут только по конкретному id. И вместо одного описка по кластерному индексу, вы предлагаете к поиску по обычному индексу добавить lookup из кластерного.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072636
Фотография Александр Гладченко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex,

Читайте внимательно то, что критикуете :)
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072637
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гладченко
msLex,

Читайте внимательно то, что критикуете :)




Я прекрасно прочитал ваш пост полностью, и никакой "не кванторности" в нем нет.
Все предельно просто и ясно. "Сделал кластерный PK по ID - безграмотный дизайнер таблиц!"
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072638
Фотография Александр Гладченко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex,
Вы же взрослый и опытный человек, а никак читать не научитесь?! Почему Вы забыли о контексте обсуждений?
Вы ещё мне вмените таблицы, используемые для связей...
Если для нормальной работы рядом с кластерным индексом приходится делать такой же не кластерный - речь об этом.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072641
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гладченко
msLex,
Вы же взрослый и опытный человек, а никак читать не научитесь?! Почему Вы забыли о контексте обсуждений?
Вы ещё мне вмените таблицы, используемые для связей...
Если для нормальной работы рядом с кластерным индексом приходится делать такой же не кластерный - речь об этом.


Я достаточно хорошо читаю, чтобы видеть в вашем сообщении (даже в контексте обсуждения исходной проблемы) четкий посыл: кластерный по ID - бездарь.


Обычно, в случаях когда хотят подчеркнуть частые ошибки или некие паттерны проектирования, используют слова вида "В большинстве случаев", "Очень редко" и т.п.

В вашем же сообщении, утверждение совершенно безапелляционны.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072642
Фотография Александр Гладченко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex,

Привет от Целко :)
Да, безапеляционны, потому что исключения очень редки, а айдиотизм я встречаю повсюду и массово.
Десеть раз подумайте, прежде чем сделать ID кластеризованным первичным ключом.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072645
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гладченко
Привет от Целко :)

Спасибо. И ему тоже.

Александр Гладченко
Десеть раз подумайте, прежде чем сделать ID кластеризованным первичным ключём.





Десять раз подумать нужно перед выбором любого из полей в качестве PK, ключа кластерного индекса и много еще чего. Но это не делает "айдиотом" того, кто сделал этот выбор обдуманно.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072651
Фотография Александр Гладченко
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex,

Вот с этим я не буду спорить, т.к. это и хотел сказать, только в "шутливой" форме :)
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072653
Кесарь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гладченко
Это, увы, очень часто встречающаяся ситуация :(
Кластерный индекс по IDENTITY да ещё и первичный ключ - это вершина безграмотности дизайнера таблицы :) Вспомните труды одного славного парня, который таких горемык называл айдиотами
Кластерный индекс хорош при просмотрах полных и не полных, и когда нужно выдать много колонок.
Некластерный индек как раз для поиска хорошо работает, и первичный ключ по некластерному тут будет оптимизатору завсегда удобней.


Александр, вы имеете в виду, что кластерный индекс должен включать все поля таблицы или весьма значительную их часть?


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

И делали не самые глупые люди. Которые и на этом форуме присутствовали несколько ранее.

Как же так?
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072677
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ситуации могут быть разными и нельзя сказать, что в подавляющем количестве случаев выбор нумератора в качестве кластерного ключа - наихудший вариант. Соглашусь с msLex, в том, что необходима оценка практичности такого решения с учетом особенностей индексов в кластеризованных таблицах.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072744
uaggster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
msLex
Александр Гладченко
Кластерный индекс по IDENTITY да ещё и первичный ключ - это вершина безграмотности дизайнера таблицы


Вы же взрослый, опытный человек, а так безапелляционный несете чушь.


Я сходу назову две ситуации, при которых "кластерный индекс по IDENTITY да ещё и первичный ключ" лучший (если не единственный вариант)

1. Таблица а-ля очередь, к которой все запросы имею вид select top N ... from ... where id > @id order by id
2. Таблица, к которой все (ну или основная масса) запросы идут только по конкретному id. И вместо одного описка по кластерному индексу, вы предлагаете к поиску по обычному индексу добавить lookup из кластерного.

Как минимум - есть еще один + -- int identity еще и лёгкий.
https://www.sql.ru/articles/mssql/03013101indexes.shtmlКаждый некластерный индекс будет использовать значения кластерного индекса. Следовательно увеличение размера кластерного индекса приводит к многократному увеличению требований по памяти для всех не кластерных индексов. Последнее приводит к увеличению времени на процессы чтения, сканирования данных и, как следствие, к снижению общей производительности системы. Еще одно наблюдение – увеличение длины ключа приводит к снижению количества записей индекса, способных уместиться в пределах одной страницы, как следствие – к увеличению операций чтения-записи. Рис.6 показывает как строится некластерный индекс поверх кластерного.
https://www.sql.ru/articles/mssql/03013101indexes.shtml

Сходу, кластерный индекс, отличный от синтетического PK - хорош только в неизменяемых справочниках, ну, еще иногда в хранилищах.
А в OLTP доступ обычно к конкретной записи, по конкретному, совершенно абстрактному и не привязанному к смыслу хранимых данных ключу.
Какой вариант подходит лучше чем int identity?
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072745
Кесарь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
uaggster
Сходу, кластерный индекс, отличный от синтетического PK - хорош только в неизменяемых справочниках, ну, еще иногда в хранилищах.
А в OLTP доступ обычно к конкретной записи, по конкретному, совершенно абстрактному и не привязанному к смыслу хранимых данных ключу.
Какой вариант подходит лучше чем int identity?


Bigint очевидно! :)
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072749
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
uaggster
Сходу, кластерный индекс, отличный от синтетического PK - хорош только в неизменяемых справочниках, ну, еще иногда в хранилищах.

А вот это точно не так.
Любые запросы по некластерному индексу, будут требовать либо включения всех требуемых полей в include секцию, что приводит и к увеличению объема данных, и к большему количеству операций при модификации данных, либо к появлению key lookup-ов.


Причем, если поиск сам поиск группы значений в некластерном будет выполнятся за один "спуск по дереву" и последующий range scan, то каждый key lookup, это отдельный поиск в кластерном индексе, и он очень сильно замедляет скорость выполнения запроса.



Классический (для меня) пример плохого кластерного по id я первый раз увидел лет 15 назад.
Обычная таблица документов (счета и т.п.) с кластерным индексом по ID и основные запросы вида select .. from .. where create_date beetwen ....
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072784
Кесарь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Но тогда как совместить?

это:

"Каждый некластерный индекс будет использовать значения кластерного индекса. Следовательно увеличение размера кластерного индекса приводит к многократному увеличению требований по памяти для всех не кластерных индексов."

с этим:

msLex
Любые запросы по некластерному индексу, будут требовать либо включения всех требуемых полей в include секцию, что приводит и к увеличению объема данных, и к большему количеству операций при модификации данных, либо к появлению key lookup-ов.


Видимо уменьшением кластерного индекса до ровно одного поля с ID, покрывающими индексами и наконец уменьшением ширины таблицы. С вынесением всех необязательных, справочных, "плавающих" данных в присоединённые таблицы, строго специализированные (в них стараться иметь минимум полей и кластерный индекс по всем полям).



msLex
Классический (для меня) пример плохого кластерного по id я первый раз увидел лет 15 назад.
Обычная таблица документов (счета и т.п.) с кластерным индексом по ID и основные запросы вида select .. from .. where create_date beetwen ....


А как надо?
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072788
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кесарь
msLex
Классический (для меня) пример плохого кластерного по id я первый раз увидел лет 15 назад.
Обычная таблица документов (счета и т.п.) с кластерным индексом по ID и основные запросы вида select .. from .. where create_date beetwen ....


А как надо?


для этого конкретного запроса, идеальным будет кластерный индекс по create_date
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072789
Кесарь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex
Кесарь
пропущено...


А как надо?


для этого конкретного запроса, идеальным будет кластерный индекс по create_date


Ну знаете, так я и сам ответить могу. Очевидно в жизни к таблице обращаются не с одним видом запроса.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072800
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кесарь
msLex
пропущено...


для этого конкретного запроса, идеальным будет кластерный индекс по create_date


Ну знаете, так я и сам ответить могу. Очевидно в жизни к таблице обращаются не с одним видом запроса.



Вот некая интегральная оценка частоты и сложности запросов получения и изменения данных и является "мерилом" выбора индексов и всего прочего.


В том конкретном случае, на любой запрос по ключу документа был предварительный запрос с получением списка документов за диапазон (сегодня по умолчанию) дат.
И кластерный индекс по create_date был бы оптимальным решением.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072801
Кесарь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
msLex
В том конкретном случае, на любой запрос по ключу документа был предварительный запрос с получением списка документов за диапазон (сегодня по умолчанию) дат.
И кластерный индекс по create_date был бы оптимальным решением.


Кудряво! Ну в таком случае оно конечно.
...
Рейтинг: 0 / 0
Некластерный индекс по полям кластерного. В чем фишка?
    #40072871
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кесарь
msLex
В том конкретном случае, на любой запрос по ключу документа был предварительный запрос с получением списка документов за диапазон (сегодня по умолчанию) дат.
И кластерный индекс по create_date был бы оптимальным решением.


Кудряво! Ну в таком случае оно конечно.

а если подумать то оказывается что даты как раз хороший кандидат на партицирование, а не кластеризацию
...
Рейтинг: 0 / 0
48 сообщений из 48, показаны все 2 страниц
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Некластерный индекс по полям кластерного. В чем фишка?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]