|
|
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
да, пардон, первая колонка sum_ss это user_seeks + user_scans из sys.dm_db_index_usage_stats ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2021, 19:03 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Yasha123 у меня подобные 2 индекса, ПК и уникальный, один кластерный, другой некластерный, на широченной таблице. некластерный, разумеется, гораздо меньше весит, лично мне надо для проверки ФК, ибо на эту таблицу смотрит туча других. вот статистика по чтениям, сервер еще как обрадовался новому некластерному и юзает его, хотя сделан не так давно: А не могли бы вы написать список полей обоих индексов для понимания? А то что-то я не догоняю, в чём смысл. Было бы интересно понять это решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2021, 13:06 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Кесарь Yasha123 у меня подобные 2 индекса, ПК и уникальный, один кластерный, другой некластерный, на широченной таблице. некластерный, разумеется, гораздо меньше весит, лично мне надо для проверки ФК, ибо на эту таблицу смотрит туча других. вот статистика по чтениям, сервер еще как обрадовался новому некластерному и юзает его, хотя сделан не так давно: А не могли бы вы написать список полей обоих индексов для понимания? А то что-то я не догоняю, в чём смысл. Было бы интересно понять это решение. Насколько я понял: если индекс используется для выборки нескольких/многих/всех полей из этой же таблицы - используется кластерный индекс. Если индекс используется только как ссылочный элемент/малая выборка - используется некластерный индекс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2021, 21:28 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Это, увы, очень часто встречающаяся ситуация :( Кластерный индекс по IDENTITY да ещё и первичный ключ - это вершина безграмотности дизайнера таблицы :) Вспомните труды одного славного парня, который таких горемык называл айдиотами Кластерный индекс хорош при просмотрах полных и не полных, и когда нужно выдать много колонок. Некластерный индек как раз для поиска хорошо работает, и первичный ключ по некластерному тут будет оптимизатору завсегда удобней. То, что встречаются такие "сладкие" парочки с дублем колонок кластерного индекса - это компромис, чтобы малой кровью исправить чью то глупость. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 10:25 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко Кластерный индекс по IDENTITY да ещё и первичный ключ - это вершина безграмотности дизайнера таблицы Вы же взрослый, опытный человек, а так безапелляционный несете чушь. Я сходу назову две ситуации, при которых "кластерный индекс по IDENTITY да ещё и первичный ключ" лучший (если не единственный вариант) 1. Таблица а-ля очередь, к которой все запросы имею вид select top N ... from ... where id > @id order by id 2. Таблица, к которой все (ну или основная масса) запросы идут только по конкретному id. И вместо одного описка по кластерному индексу, вы предлагаете к поиску по обычному индексу добавить lookup из кластерного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 10:34 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
msLex, Читайте внимательно то, что критикуете :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 10:37 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко msLex, Читайте внимательно то, что критикуете :) Я прекрасно прочитал ваш пост полностью, и никакой "не кванторности" в нем нет. Все предельно просто и ясно. "Сделал кластерный PK по ID - безграмотный дизайнер таблиц!" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 10:40 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
msLex, Вы же взрослый и опытный человек, а никак читать не научитесь?! Почему Вы забыли о контексте обсуждений? Вы ещё мне вмените таблицы, используемые для связей... Если для нормальной работы рядом с кластерным индексом приходится делать такой же не кластерный - речь об этом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 10:45 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко msLex, Вы же взрослый и опытный человек, а никак читать не научитесь?! Почему Вы забыли о контексте обсуждений? Вы ещё мне вмените таблицы, используемые для связей... Если для нормальной работы рядом с кластерным индексом приходится делать такой же не кластерный - речь об этом. Я достаточно хорошо читаю, чтобы видеть в вашем сообщении (даже в контексте обсуждения исходной проблемы) четкий посыл: кластерный по ID - бездарь. Обычно, в случаях когда хотят подчеркнуть частые ошибки или некие паттерны проектирования, используют слова вида "В большинстве случаев", "Очень редко" и т.п. В вашем же сообщении, утверждение совершенно безапелляционны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 10:51 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
msLex, Привет от Целко :) Да, безапеляционны, потому что исключения очень редки, а айдиотизм я встречаю повсюду и массово. Десеть раз подумайте, прежде чем сделать ID кластеризованным первичным ключом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 10:53 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко Привет от Целко :) Спасибо. И ему тоже. Александр Гладченко Десеть раз подумайте, прежде чем сделать ID кластеризованным первичным ключём. Десять раз подумать нужно перед выбором любого из полей в качестве PK, ключа кластерного индекса и много еще чего. Но это не делает "айдиотом" того, кто сделал этот выбор обдуманно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 11:00 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
msLex, Вот с этим я не буду спорить, т.к. это и хотел сказать, только в "шутливой" форме :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 11:03 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко Это, увы, очень часто встречающаяся ситуация :( Кластерный индекс по IDENTITY да ещё и первичный ключ - это вершина безграмотности дизайнера таблицы :) Вспомните труды одного славного парня, который таких горемык называл айдиотами Кластерный индекс хорош при просмотрах полных и не полных, и когда нужно выдать много колонок. Некластерный индек как раз для поиска хорошо работает, и первичный ключ по некластерному тут будет оптимизатору завсегда удобней. Александр, вы имеете в виду, что кластерный индекс должен включать все поля таблицы или весьма значительную их часть? Но то, что вы называете глупостью, используется например в одной известной вам компании в комплексе учётных систем, и всё в целом работает неплохо даже после дикого роста последних лет. Не без проблем, конечно, но работает. И делали не самые глупые люди. Которые и на этом форуме присутствовали несколько ранее. Как же так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 11:13 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Ситуации могут быть разными и нельзя сказать, что в подавляющем количестве случаев выбор нумератора в качестве кластерного ключа - наихудший вариант. Соглашусь с msLex, в том, что необходима оценка практичности такого решения с учетом особенностей индексов в кластеризованных таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 11:54 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
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? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 14:47 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
uaggster Сходу, кластерный индекс, отличный от синтетического PK - хорош только в неизменяемых справочниках, ну, еще иногда в хранилищах. А в OLTP доступ обычно к конкретной записи, по конкретному, совершенно абстрактному и не привязанному к смыслу хранимых данных ключу. Какой вариант подходит лучше чем int identity? Bigint очевидно! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 14:50 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
uaggster Сходу, кластерный индекс, отличный от синтетического PK - хорош только в неизменяемых справочниках, ну, еще иногда в хранилищах. А вот это точно не так. Любые запросы по некластерному индексу, будут требовать либо включения всех требуемых полей в include секцию, что приводит и к увеличению объема данных, и к большему количеству операций при модификации данных, либо к появлению key lookup-ов. Причем, если поиск сам поиск группы значений в некластерном будет выполнятся за один "спуск по дереву" и последующий range scan, то каждый key lookup, это отдельный поиск в кластерном индексе, и он очень сильно замедляет скорость выполнения запроса. Классический (для меня) пример плохого кластерного по id я первый раз увидел лет 15 назад. Обычная таблица документов (счета и т.п.) с кластерным индексом по ID и основные запросы вида select .. from .. where create_date beetwen .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 15:01 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Но тогда как совместить? это: "Каждый некластерный индекс будет использовать значения кластерного индекса. Следовательно увеличение размера кластерного индекса приводит к многократному увеличению требований по памяти для всех не кластерных индексов." с этим: msLex Любые запросы по некластерному индексу, будут требовать либо включения всех требуемых полей в include секцию, что приводит и к увеличению объема данных, и к большему количеству операций при модификации данных, либо к появлению key lookup-ов. Видимо уменьшением кластерного индекса до ровно одного поля с ID, покрывающими индексами и наконец уменьшением ширины таблицы. С вынесением всех необязательных, справочных, "плавающих" данных в присоединённые таблицы, строго специализированные (в них стараться иметь минимум полей и кластерный индекс по всем полям). msLex Классический (для меня) пример плохого кластерного по id я первый раз увидел лет 15 назад. Обычная таблица документов (счета и т.п.) с кластерным индексом по ID и основные запросы вида select .. from .. where create_date beetwen .... А как надо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 16:16 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Кесарь msLex Классический (для меня) пример плохого кластерного по id я первый раз увидел лет 15 назад. Обычная таблица документов (счета и т.п.) с кластерным индексом по ID и основные запросы вида select .. from .. where create_date beetwen .... А как надо? для этого конкретного запроса, идеальным будет кластерный индекс по create_date ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 16:24 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
msLex Кесарь пропущено... А как надо? для этого конкретного запроса, идеальным будет кластерный индекс по create_date Ну знаете, так я и сам ответить могу. Очевидно в жизни к таблице обращаются не с одним видом запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 16:27 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Кесарь msLex пропущено... для этого конкретного запроса, идеальным будет кластерный индекс по create_date Ну знаете, так я и сам ответить могу. Очевидно в жизни к таблице обращаются не с одним видом запроса. Вот некая интегральная оценка частоты и сложности запросов получения и изменения данных и является "мерилом" выбора индексов и всего прочего. В том конкретном случае, на любой запрос по ключу документа был предварительный запрос с получением списка документов за диапазон (сегодня по умолчанию) дат. И кластерный индекс по create_date был бы оптимальным решением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 16:44 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
msLex В том конкретном случае, на любой запрос по ключу документа был предварительный запрос с получением списка документов за диапазон (сегодня по умолчанию) дат. И кластерный индекс по create_date был бы оптимальным решением. Кудряво! Ну в таком случае оно конечно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 16:46 |
|
||
|
Некластерный индекс по полям кластерного. В чем фишка?
|
|||
|---|---|---|---|
|
#18+
Кесарь msLex В том конкретном случае, на любой запрос по ключу документа был предварительный запрос с получением списка документов за диапазон (сегодня по умолчанию) дат. И кластерный индекс по create_date был бы оптимальным решением. Кудряво! Ну в таком случае оно конечно. а если подумать то оказывается что даты как раз хороший кандидат на партицирование, а не кластеризацию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2021, 19:32 |
|
||
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1684678]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
138ms |
get topic data: |
11ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 344ms |
| total: | 588ms |
| 0 / 0 |
