Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
кириллk Member Откуда: Сообщений: 1058 |
Есть таблица с городами (все города уникальные) (Id , name) я могу сделать 1. первичный ключ по полю Id 2. кластерный индекс по полю Id 3. уникальный кластерный индекс по полю Id Я сделал по очереди все 3 и разницы в производительности не нашел Если ли разница для данной задачи? Спасибо |
17 ноя 15, 18:36 [18431270] Ответить | Цитировать Сообщить модератору |
AlanDenton Member [скрыт] Откуда: Сообщений: 1004 |
кириллk, 1. PK - кластерный ключ и ограничение уникальности 2. кластерный ключ, но вставлять можно дубликаты 3. грубо говоря, тоже что и первое - на дубликаты будет ругаться с точки зрения производительности поиск идет и идентичной структуры в обеих случаях. есть конечно исключения в плане с UNIQUE и без, но это отдельная тема. |
17 ноя 15, 18:41 [18431298] Ответить | Цитировать Сообщить модератору |
кириллk Member Откуда: Сообщений: 1058 |
А можно ссылочку на "есть конечно исключения в плане с UNIQUE и без" |
||
17 ноя 15, 18:45 [18431316] Ответить | Цитировать Сообщить модератору |
Minamoto Member Откуда: Москва Сообщений: 1162 |
кириллk, ну вот, например: http://aboutsqlserver.com/2011/11/24/a-few-more-words-about-uniquifiers-and-uniqueness-of-the-clustered-index/ Смысл в том, что если кластерный ключ неуникален, SQL Server добавляет в него uniquefier, чтобы сделать его уникальным. Соответственно ключ увеличивается в размере и это снижает производительность. Поэтому, если можете сделать ключ уникальным - делайте. |
17 ноя 15, 18:53 [18431367] Ответить | Цитировать Сообщить модератору |
AlanDenton Member [скрыт] Откуда: Сообщений: 1004 |
кириллk, ссылку предоставить не смогу... сайт вроде был mssqltips. главная идея была такая - если по строкам всегда ожидаются уникальные значения значит нужно ставить UNIQUE а на плане это выражалось в то что использовалась менее затратная операция string aggregation... вместо hash match вообще-то мне тоже стало интересно. если будет возможность @SomewhereSomehow поделитесь пожалуйста соображениями по этому поводу. Если разница в перфомансе между unique & non-unique index на примере агрегации данных. заранее спасибо. |
17 ноя 15, 18:54 [18431371] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8350 |
кириллk, если Вы идете в направлении повышения скорости выборки данных, то Ваши действия, в общем-то не особо с этим соотносятся. Скорее всего, Вы не понимаете чем отличается первичный ключ от кластерного индекса. |
17 ноя 15, 18:56 [18431386] Ответить | Цитировать Сообщить модератору |
кириллk Member Откуда: Сообщений: 1058 |
Владислав Колосов, Понимаю. У меня вот какая идея. Сейчас у меня везде первичные ключи. и вставка данных очень долго идет. я думаю переделать на уникальные индексы и дропать их перед вставкой а потом снова инсертить |
17 ноя 15, 19:00 [18431407] Ответить | Цитировать Сообщить модератору |
babona Member [заблокирован] Откуда: Батуринск Сообщений: 1816 |
гениально! |
17 ноя 15, 21:51 [18432163] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8350 |
кириллk, как же вы понимаете, если у Вас в голове первичный ключ и кластерный индекс - это одно и то же. |
18 ноя 15, 10:49 [18433930] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
Первичный ключ в MSSQL реализуется уникальным индексом. Если явно не указать nonclustered, то, по умолчанию, кластерным. Тут на форуме несколько лет назад была тема https://www.sql.ru/forum/922495/otlichie-pervichnogo-klucha-ot-unikalnogo-indeksa, не хочется повторяться рассказывая про отличия. С точки зрения производительности имеет значение уникальный/неуникальный и кластерный/некластерный индекс.
Для какой задачи? Описания задачи не увидел. Если речь просто о справочнике городов, то я бы сделал первичный ключ на ID и не заморачивался. Что касается уникальности. Разница в производительности конечно есть. Самый простой пример, в случае поиска по индексу и точечного запроса для уникального индекса может быть использован метод доступа Key Seek – это самый быстрый способ, остальные используют Seek + Partial Scan. (если не включать недокументированных TF, то в плане этого не увидишь). Пример посложнее, но более существенный в смысле производительности связан с приемами оптимизации. Например, в случае уникального индекса оптимизатор может избавляться от группировки, если она идет по уникальному столбцу, либо, более реалистичный пример, двигать группировку до/после соединения, в зависимости что дешевле, без риска нарушить семантику запроса (показывал примеры на докладе 24HOP соединения – есть на ютюбе, кому интересно). Или более низкоуровневый пример. Допустим, вы нашли страницу, но вам надо еще найти запись на странице. Рекомендую три статьи, кому интересно: Enforcing Uniqueness for Performance Avoiding Uniqueness for Performance SQL Server, Seeks, and Binary Search Если спуститься с уровня Query Processor совсем низко, до уровня Storage Engine, то в таблице вообще нет не уникальных строк. Процитирую Пола Рэндала: ![]() Резюмируя, как тут уже сказали выше, если можете сделать индекс уникальным – делайте. К тому же, это нужно делать не только с точки зрения производительности, но и с точки зрения корректности данных. |
||
18 ноя 15, 11:58 [18434487] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
вообще-то Рэндал про ключи сказал. т.е. речь об индексах. разумеется, ключ это вообще не ключ, если он неуникален. а просто строки в таблице почему не могут быть неуникальными? не, ну разумеется, у любого добра, где-то записанного, есть уникальный адрес. но адрес адресом, а сама строка в куче (data row) может повторяться. в отличие от строки индекса (index row), где uniquifier (в случае неуникального ключа) добавлен физически как часть строки |
||
18 ноя 15, 12:12 [18434585] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
o-o,
Что непонятно? Вот вся переписка:
Почему не могут быть не уникальными? Вот хотя бы для "keeps track of where a scan is"... В любом случае, есть индекс или нет, сервер должен уметь однозначно определять строку в таблице. Представьте хотя бы поиск по некластерному индексу, должен же он уметь делать RID Lookup. Так что не уникальных строк с точки зрения SE нет. Другой вопрос как он это делает, дописывает ли унификатор или хранит в некластерном индексе RID записи - без разницы. |
||||
18 ноя 15, 12:45 [18434828] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
SomewhereSomehow, в приведенной переписке снова ни слова о *кучах*, зато вновь о КЛЮЧАХ. ключ не может быть неуникальным. ключ это то, по чему строят индекс. ключ индекса, это не то, что "видит пользователь", когда указывает некий ключ в CREATE INDEX. это то, что делает строки различными. и когда мы объявляем командой нечто ключом, и это нечто неуникально, будет добавлен uniquifier. *физически* добавлен будет, чтобы действительно получился ключ. ----- приведу пример. у меня одноколоночная куча: create table dbo.t (id int); insert into dbo.t(id) values (1) go 1000 в куче 1000 строк, одно и то же значение 1. одинаковы ли мои строки или они различны? строки НЕУНИКАЛьНЫ. они идентичны. при этом у них разный RID. но к строкам ничего не добавлено, это близнецы, живущиe по разным адресам. а теперь я из этой кучи делаю кластерную таблицу строки изменятся, каждой из них добавят uniquifier. близняшек теперь можно различить не по месту жительства. им каждому выдали табличку с надписью "единица номер один", "единица номер два", ... а могли не делать кластерную таблицу. пускай куча. но построить некластерный индекс. ключ типа id: create index ix_t on dbo.t(id) но ключ этого индекса -- никакое не id, при построении индекса будет добавлен uniquifier (RID исходной кучи в качестве него). что, есть ли разница между строками исходной кучи и строками индекса на ней, по тому же единственному полю id? да, есть. и dbcc page покажет различное содержимое этих строк. не только на листовом уровне, где они обязаны хранить указатель на базовую таблицу. в самом индексе они различны (level1), и различаются не своими RID (они же у них тоже есть) а "той табличкой, что им выдали для их различия", RID в исходной таблице ------- на картинке показана куча и некластерный индекс на ней. 2-ое окно -- это нелистовой уровень индекса. RID-ы в явном виде добавлены. от исходной кучи. чтобы зауникалить строки. а если вашей логике следовать, то занафига. и так каждая строка уникальна *своим* RID-ом. а тут типа у строк у каждой свой адрес (RID) -- это атрибут, а не кусок строки -- и еще и RID исходной таблицы -- уже именно часть строки и ключа (что подписано в выводе dbcc page) ------- извиняюсь за занудность К сообщению приложен файл. Размер - 47Kb |
18 ноя 15, 14:01 [18435424] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
o-o, Вы к чему это все написали? То что в таблице могут храниться одинаковые строки с точки зрения данных? Давайте еще раз, внимательно почитаем (я даже выделю, если непонятно):
Я не говорю о том могут ли в таблице быть дубликаты строк с точки зрения данных. Я не говорю о том, что считать ключом, а что нет. Я не говорю о том, как реализуется уникальность строки для кучи или кластерного индекса. Я говорю о том, что (еще раз):
При чем тут унификаторы? При чем тут что дописывается и хранится?
Это вы какой-то вашей логике следуете. Домысливаете то, что я не говорил. Я говорил о принципиальной концепции - нет не уникальных строк с точки зрения SE. Вы же говорите о реализации, при этом смешивая в кучу уровни абстракции работы сиквела, что где кто дописыват, как хранит и т.д. При этом сами приводите пример, что строки уникальны с точки зрения SE. В чем спор? Если хотите поговорить о том, как реализована уникальность - это отдельный разговор - создавайте тему, описывайте эксперименты, если хотите дискуссии - ставьте вопросы. Но не думаю, что мне будет это интересно, т.к. все это прописные истины, пройденные давно. Короче, я не понимаю сути вашего вопроса. Я говорю, что на уровне SE строки уникальны. Не согласны - Давайте репро. П.С. А то что люди пишут в твиттере не выверяя каждую букву, как для документации и текст не проходит ревью нескольких специалистов, а Пол Рэндал называет ключами не совсем то, что имеется ввиду в энциклопедии - смиритесь с этим, не надо цепляться к его словам и терминам, когда и так понятно, что имелось ввиду. Хотя можете конечно ему написать, дескать, watch your speech =) Но это бред. |
||||||
18 ноя 15, 14:32 [18435654] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
это вы приписываете свою трактовку словам Рэндала. в третий раз: Рэндал и его собеседник говорят о ключах. и фраза на картинке "для SE нет неуникальных КЛЮЧЕЙ"
а вы переиначили на "нет не уникальных СТРОК с точки зрения SE". это не только искажение фразы, но и искажение действительности. а репро оно и кодом, и на картинке. имеем кучу. в ней 1000 строк. они уникальны? НЕТ а адреса их уникальны? разумеется. все строки в куче физически хранят лишь значение колонки. ничего в строку не добавлено. а если речь идет о ключе? сделаем это же самое поле id ключом некластерного индекса. чтобы воспроизвести то, о чем говорит Рэндал. что должно лежать в строках нелистового уровня? только ключ (вроде бы id?) и указатель на страницу, куда идем дальше в нашем поиске. а что лежит физически? в качестве ключа лежит id и RID из исходной таблицы. имеем *уникальные* строки. они не своими адресами уникальны, а содержимым. к каждому id еще в довесок уникализотор в виде RID добавлен. вот про это говорит Рэндал, а не про то, что у любой структуры в памяти еесть уникальный адрес |
||||
18 ноя 15, 14:49 [18435806] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
у меня не было никакого вопроса. когда я что-то спрашиваю, в конце предложения ставлю вопросительный знак. у меня было опровержение/уточнение вашего перевода фразы Рэндала.
кстати, я не буду 4 страницы спорить и обзываться. мне кажется, пошел такой вирус склочничества со вчерашнего дня, слишком много ядовитой слюной брызгали, вот вам и последствия. кому нравится ваш перевод, пусть с тем и сидит, а мое несогласие и его обоснование см. выше |
||||||
18 ноя 15, 14:58 [18435908] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
o-o, ок, принято. |
18 ноя 15, 15:27 [18436148] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
вот и прекрасно. и мне понятно, о чем вы. и тоже принято :) вы просто не ту цитату привели в подтверждение своих слов. видно было по самой фразе, а когда вы предшествующую ей привели, ну там уже вообще однозначно об индексах с неуникальными ключами:
не-не, даже в твиттерах товарищи вещи своими именами называют :) |
||||||
18 ноя 15, 15:46 [18436296] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
Отвечал на последнее сообщение, этот выпад принять не могу.
Я не переиначил, я обобщил, только с целью сказать, что нет не уникальных строк на уровне SE. ВНИМАТЕЛЬНО читайте что написано
Искажение действительности??? Серьезно? А мы об одной действительности говорим? Такое высказывание заставляет спросить: А вы понимаете что такое Storage Engine? Из вашего сообщения я понимаю, что для вас это просто структуры данных.
И чего? Не добавлено в строку - это по вашему значит, что строка с точки зрения SE не уникальна? |
||||||||
18 ноя 15, 15:53 [18436366] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
Не всегда. Какой ваш твиттер? |
||||
18 ноя 15, 15:54 [18436374] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
SomewhereSomehow, Нет у меня никакого твиттера и добавить мне больше нечего. Только вроде сошлись на том, что друг друга поняли, как все по-новой. Я не спорю с вашими рассуждениями, но приведенная цитата не их подверждает, а конкретный случай неуникальных ключей. Вы ее привели не в тему, перевели спецом неверно, чтобы подогнать под свои рассуждения, но она о том, о чем я, а я об этих несчастных неуникальных ключах, и не от фонаря, а ровно в ответ на ту цитату. Можем мы разорвать этот круг или нет? --- Мне точно надоело, но если хотите, щас напишу Рэндалу от имени школьников, практикующихся в переводе вольных постов из твиттера. Спрошу: дяденька, вы тут отвечаете на конкретный вопро White - a, заданный в 2013ом году, или подтвержаете рассуждения SomewhereSomehow? |
18 ноя 15, 16:12 [18436509] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
o-o, Напишите конечно, только сформулируйте свой вопрос правильно. Например: Уникальны ли строки таблицы для SE. И не надо всяких уточнений типа есть кластерный индекс, уникальный ли он, или его нет и т.д. А цитату я привел правильно. Ведь речь в любом случае шла об индексе, нет? Читаем внимательно опять.
Это вы приплели кучу. Можно даже без всяких обобщений взять контекст вопроса и рассматривать цитату там. Нет? =) Так что это ВЫ увидели в строках индекса - строки кучи. Облом по всем статьям. Но я даже согласен обобщить мое заявление и на кучу тоже. Ну сами подумайте, (упаси бог вникать в ваши рассуждения что и как хранится - есть хорошие книги для этого, где все наглядно, а еще это 10 лет назад примерно) - ну удаление из кучи на которой есть не кластерный индекс. Нашли мы по индексу значение, ну надо же определить конкретную строку. Так что спрашивайте Пола - не спрашивайте - а реальность такая, что для SE нет не уникальных строк. Я, кстати, немного в шоке, что приходится столько писать про это, особенно вам. Вы же вроде хороший специалист. Троллите меня чтоль или правда не понимаете о чем я? Может прицепились к словам, а теперь сами не рады? |
||
18 ноя 15, 16:34 [18436645] Ответить | Цитировать Сообщить модератору |
SomewhereSomehow Member Откуда: Moscow Сообщений: 2480 Блог |
SomewhereSomehow, Если верно последнее, то давайте просто не будем терять лицо и скажем, что произошло недопонимание, которое теперь устранено и все встало на свои места. А правы все =)) |
18 ноя 15, 16:40 [18436687] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
SomewhereSomehow, Скажите, куда ему написать, и я напишу. Я не буду приплетать форум и кучи. Я приведу ту самую цитату полностью и спрошу, о чем это тут? А то у меня проблемы с инглишем и никак не пойму, тут о неуникальных значеничх ключа или о чем другом (ведь люди в твиттере под indexes with duplicate keys не имеют в виду индексы с неуникальными ключами, правда?) Посоветуйте блог или адрес, куда можно такое вот послание отправить, в блоге он точно отвечает, а вот где он свою твиттеровскую переписку обсуждает, я не знаю |
18 ноя 15, 16:46 [18436734] Ответить | Цитировать Сообщить модератору |
Winnipuh Member [заблокирован] Откуда: Київ Сообщений: 10428 |
https://twitter.com/paulrandal |
||
18 ноя 15, 16:48 [18436742] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |