Всем привет. у кого есть опыт, что быстрее работает в запросе? если делать отбор по строке или уникальному идентификатору. записей более 10 мил.

(0) Сам как думаешь?

"в запросе ... делать отбор по ... уникальному идентификатору." // Это как?

Строка это like?

(2) Ну, как обычно.

Индекс по этому полю

В каком запросе?

(0) однозначно сказать нельзя. В каждом случае нужно тестировать производительность на живых данных.

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

(0) Ссылка это 16 байт. Скорее всего индекс ref по объёму меньше индекса строки, от сюда I/O будет меньше и тем самым поиск по ref будет быстрее.

(0) Важно только "в индексе / не в индексе".

строка на 16 байт - это всего 8 символов

(11) Я думаю что в индексе для строк используешься хэш функция и скорее всего индекс так же содержит исходное поле

(10) еще важна селективность индекса

(13) Для GUID селективность высокая, да и для строк скорее всего так же

(14) Не факт. Например ТЧ документа на 10тыщ строк

Мои мысли: отбор по УИД, это скорее всего кластерный индекс, а в нем много всяких других полей. Индекс по строке  - содержит сму строку + мниимум (в зависимости от данных). Получается во втором случаее на одной странице данных больше вариантов и меньшее количество страниц будет считано во время "индекс сик". В чем моя ошибка?

(15) Ты думаешь что каждая строка табличной части в индексе занимает по одной записи в индексе? А не блок ссылок на станицы, с указанием позиции в ней?

(16) А что такое кластер :) И как физически распределяется хранение ссылок в кластерном индексе?

(16) по-твоему, поиск в кластерном индексе - это всегда скан?

(19) Нет, там тоже индекс сик. Но данных ведь больше на странице. Значит и количество страниц раве не будет прочтено больше в итоге?

(17) чем блок ссылок отличается от самих ссылок?

(20) почему данных то больше?

(22) Это я фантазирую: индекс по ID включает большее кол-во столбцов. Да, мои мысли ошибочны. Спасибо.

В физическом хранении. Есть в ссылка, которая идёт в индексе уже отсортированная. В блоках. Нахождение такой ссылки делается так: считывается первый, последний и средний блок. Идёт проверка в каком из диапазонов лежит ссылка, таким образом после первой проверки идёт уполавинивание данных для поиска. Так деля на диапазоны выискивается блок где содержится ссылка, далее в найденных данных есть указание что все 10000 ссылок указаны в таком то блоке, и идёт считывание цепи страниц с ссылками. Это моё предположение, ведь нафейхуа увеличивать индекс дубликатами?

(16) отбор по УИД это кластерный индекс если этот УИД является, например, ссылкой справочника. А если УИД это какой-то реквизит регистра сведений, то это однозначно не кластерный.
Производительность индекса по строке зависит от самой строки: длины и содержания.
На мой взгляд вопрос неоднозначный. Требуется проверка и оптимизация непосредственно на реальных данных.

(23) индекс же дерево, не будет там большого кол-ва столбцов

(24) так сами данные то лежат на разных страницах.
И может случиться так, что все 10к записей данных лежат каждая в своей стрнице.
Где тут блок указать?

(25) уид - это не всегда ссылка.
например ключстроки в ЕРП в документах

(27) Ну смотри
Индекс:
[Ссылка нижележащая]   -> [Это отдельные физические страницы на случай вставки]
[Ссылка наша]           -> [Странница(ы) с указателями на физическое хранение данных]
[Ссылка вышележащая]

а что за строка?
какая длина, что хранить хочешь там

меня интересует, что будет работать быстрее тип ГУИД или строка. У меня есть уникальный идентификатор, я думаю если я его сделаю строкой, не будет ли быстрее работать запрос на выборку с отбором по этому полю.

(31) что мешает проверить?

(31) Насколько я понимаю тип сравнения будет Равно (не подобно). В таких условиях думаю что какой либо существенной разницы в производительности не будет.
Правда где-то видел в рекомендациях 1С что предпочтительнее не использовать простые типы данных в отборах в запросах. Но могу ошибаться.

(24) Ты гонишь.

(31) Пофиг.

Проверить можно, но это долго так как база большая пока тип поменяется 5 часов проходит. весит много развернуть тоже целая история. поэтому спросил у вас, может кто сталкивался. Спасибо в любом случае.

(32)Проверить можно, но это долго так как база большая пока тип поменяется 5 часов проходит. весит много развернуть тоже целая история. поэтому спросил у вас, может кто сталкивался. Спасибо в любом случае.

(31) Вопрос из серии "Кто сильнее - кит или слон". То есть, мягко говоря, не совсем корректный и умный. В деле поиска данных в базах данных нет абслоюта, который ищется заданным вопросом.

(31) Предполагаю, что по ГУИД будет немного быстрее, т.к. для этого типа данных в индексе будет использована наиболее подходящая хэш функция, тогда как для строки эта функция будет основана на общем анализе содержимого строк и, вероятно, будет хуже.

(34) Блясни познаниями, опиши процесс

(39) Если и правда интересно, https://en.wikipedia.org/wiki/B%2B_tree#Search

(38) Интересно, откуда вообще бред про хеш-функции в индексах?

(41) В некоторых индексах используются. Но не в скуле.

(41) а как по вашему индексы строятся?

(40) Ты про BTree говоришь? Про поиск в составном ключе?

http://www.sql.ru/articles/mssql/03013101indexes.shtml#3

(36) А ты проверь на маленькой.

(43) Молча. Как минимум в MS SQL без каких-либо функций. Потому здесь размышлизмы о повышении скорости поиска за счет использования каких-то функций и есть бред.

(44) WTF is "поиск в составном ключе"?

(43) См. по ссылкам (40), (44).

(47) Не тыкай, а на пальцах распиши :)

(46) Ну так просветите, уважаемый. А то критика есть, а по существу ничего не сказали.

У меня создаётся впечатление что кроме BTree дерева ничего не существует

(49) В чем просветить? Вроде однозначно написано - нет в индексах функций. Разумеется, если речь о практически используемых с 1С СУБД, а не про сферическую СУБД в вакууме, в которой, возможно, и применяются функции, в том числе и такие, которые не гарантируют уникальности возвращаемого значения при уникальных входных данных.

(46) И по поводу размышлизмов:
Индекс для типа ГУИД будет создаваться платформой 1С. По какому принципу - известно разработчикам платформы (может вам известно?). Но осмелюсь предположить, что заранее зная что хранится в этом поле, какие данные, то будет использоваться некоторый алгоритм (или хэш функция) которая позволит построить наиболее эффективный для этого поля индекс.
Что же касается строкового значения, то там может быть всё что угодно и заранее, без анализа данных, подобрать наиболее эффективный способ построения индекса проблематично. Поэтому, вероятно, индекс построенный для строки в которой записаны ГУИДы будет хуже чем индекс построенный для ГУИДов.

(49) Если вам известно как платформа строит индексы для полей разных типов, расскажите.

(51)Если вам известно как платформа строит индексы для полей разных типов, расскажите.

(52) Индекс будет создаваться СУБД по правилам СУБД. Вне зависимости от хотелок 1С. В частности, в MS SQL индексы строятся исключительно по списку полей. И никакая 1С не заставит его делать иное.

(0) Ты хочешь напрямую к SQL обращаться?
Тогда тип UUID

(55) Я видел в ИТС описание того, как платформа создает индексы для разных объектов метаданных. Например для справочников это ссылка, для документов ссылка плюс дата и.т.д. Поэтому платформа некоторым образом влияет на создание индексов.
Расскажите по каким правилам SQL создаст индекс для типа UUID и для типа STRING. Может они чем-то будут отличаться?

(57) "платформа некоторым образом влияет на создание индексов."
Разумеется, влияет. Указанием списка полей индекса. Но не более того.
"по каким правилам SQL создаст индекс для типа UUID и для типа STRING"
По одним и тем же. При создании индекса указывается только список полей.
"Может они чем-то будут отличаться?"
Своим содержимым.

(57) Платформа не создаёт индексы физически. При создании таблицы в базе данных указывается какие создавать поля, их тип, индексы, ограничения данных. Далее база сама при insert создаёт нужные индексы.

(59) "создаёт нужные индексы" читать как вставляет в индексные станицы данные

(57) "для документов ссылка плюс дата"
Create index on <Document?????> (<поле-ссылка>,<поле-дата>)

Вообще платформа для документа создаёт кластерный первичный индекс по полю Ссылка ещё уникальный индекс "Data + Ссылка" и "Номер + Ссылка"

(61) Заклинание, которые вы написали "Create index on <Document?????> (<поле-ссылка>,<поле-дата>)" это хорошо.
Но мы тут подошли к сути вопроса:
для типа UUID по какому алгоритму будет строится индекс?
для типа STRING по какому алгоритму будет строится индекс?
Какой из индексов будет эффективнее если в строку записать УИДы?

(63) Не мне вопрос, но в кластерном ( упорядоченном массиве по полю UUID ) поиск будет быстрее, чем поиск строки.

(64) Да :-)
Но по условию задачи, если это просто какой-то реквизит, то индекс будет не кластерным. Как в таком случае будет?

(63) Без алгоритмов. Просто значение поля. Некластерный индекс - вырезка из таблицы указанных полей в указанном порядке.

(63) Ну как же без алгоритмов? Какие-то алгоритмы есть, например построение дерева по некоторой по части UUIDa (это хэш функция такая) в листьях которого указатели на строки в таблице СУБД.
Я не силен в низкоуровневых алгоритмах СУБД, но точно знаю что какие-то алгоритмы используются.
Вопрос то как эффективнее хранить данные и быстрее их искать. Свои размышлизмы я высказал.

(66)Ну как же без алгоритмов? Какие-то алгоритмы есть, например построение дерева по некоторой по части UUIDa (это хэш функция такая) в листьях которого указатели на строки в таблице СУБД.
Я не силен в низкоуровневых алгоритмах СУБД, но точно знаю что какие-то алгоритмы используются.
Вопрос то как эффективнее хранить данные и быстрее их искать. Свои размышлизмы я высказал.

(65) Допустим что строка и UUID это реквизиты, тогда что в одном случае будет ссылка на кластерный индекс что в другом ( чтобы извлечь сами данные ), далее GUID это binary(16) строка может содержать больше количество символов. Точно как создаётся индекс для строк я не знаю, но я бы сделал так: на основе строки с помощью хэш функции сделал бы те же binary(16) с не уникальным индексом, далее при поиске с помощью хэш функции вычисляем ключ, далее поиск по алгоритму деления диапазона, и затем уже продолжение поиска к данных на точное сравнение строки. Если это физически происходит так, то поиск UUID теоретически быстрее

(68) Еще раз - молча, без каких-либо преобразований значений полей. Дерево строится без преобразований значений полей. Ибо эти значения потом могут (и используются) для выдачи данных без обращения к таблице. При выполнении некоторых условий, конечно же.
И не надо повторять как мантру про хэш-функцию.

(69) " binary(16) строка может содержать больше количество символов."
Чего только люди не придумают...
binary(16) - это 16 байт и не более того. Всегда 16. Байтов, произвольных.

(71) Может я плохо написал, но то что там ты вычитал я не писал

(69) Осторожнее с предположениями, вас могут обвинить в размышлизмах и бреде :-)
Я с вами согласен, но есть нюансы. Для UUID точно известна его длина и структура. На основе анализа возможных комбинаций данных можно построить хэш функцию, которая позволит вычислить ключ и наиболее эффективно построить индекс.
Со строкой всё не так однозначно т.к. длина строки разная и данные в строке тоже сильно разные. Например, во всех строках может повторяться первые 16 символов, тогда некоторые индексы (в которых хэш использует эти 16 символов) могут стать вообще неэффективными и даже замедлить работу.
Поэтому, я предполагаю, что по условию конкретно этой задачи быстрее будет использовать тип УИД.

(72) далее GUID это binary(16), строка может содержать больше количество символов.

Не хватает запятой или точки на твой выбор

(73) Серверу плевать на ваши размышлизмы и идею-фикс с хэш-функцией. Для него это 16 байт и более ничего.

(73) UUID это всего лишь сишная функция, которая позволяет генерить уникальное значение https://ru.wikipedia.org/wiki/UUID

(75) Я тебе указал что не поставил знак препинания или точку, что тебе ещё нужно?

(74) а, ну в таком случае претензий не имею. :)

(77) повнимательнее посмотри кому было написано.

(79) Да, звени не туда посмотрел

(80) звени*

(81) "и" не прожималась...

В слове "извини" вообще не бывает буквы Е.

(83) Ты знал, ты знал :) долблю и часто не смотрю на клаву

И на набранный текст, привычка с полиграфии

(75) Серверу безусловно наплевать. Но алгоритмы серверу пишут люди.
Есть алгоритмы, которые позволяют среди множества значений каждое из которых 16 байт найти искомое наиболее быстрым способом, не перебирая каждое из них. Но это лирика, мы отвлеклись от сути задачи.
Может вы выскажете ваши размышлизмы по существу задачи? Как эффективнее хранить данные в описанной ситуации?

UUID в кластере и отбор по UUID, если поиск нужно по строке и это не 1С, а к примеру Oracle, я бы тогда сделал кластерный индекс разбитый ещё и на диапазоны

(87) В Oracle это называется секционирование по диапазону, как-то так. Не знаю в MS SQL есть такие возможности или нет...

(86) Вы издеваетесь? Вы читаете что вам пишут? Поиск идет по значениям полей, в индексе значения полей и сервер не знает и знать не должен семантику данных. Для него это наборы байтов. Которые в зависимости от указанного типа можно/нельзя некоторыми способами обрабатывать. И не более того.

(89) Нисколько не издеваюсь.
Вы написали "Которые в зависимости от указанного типа можно/нельзя некоторыми способами обрабатывать".
Можете поподробнее о зависимости способа обработки от типа данных?

(90) Для строк можно использовать перекодировку, но их нельзя использовать в арифметических операциях, числа можно использовать в арифметических операциях, но нельзя перекодировать. Как и бинарные данные. Можно делать некоторые приведения типов. Это что-то для вас новое? Необычное? Непонятное?

(91) Вы немного не так меня поняли. Вопрос о поиске значения. Как наиболее эффективно найти какое-либо значение для типа Строка и для типа УИД? И обоснуйте пожалуйста.

можно вычислить конечное кол-во записей в регистре и взять число какой-то разрядности с запасом как первичный ключ. можно использовать UID. строки как маркер уникальности в регистре я бы вообще не использовал, т. к. однажды такое измерение в регистре сведений повесило базу, которую мне пришлось потом восстанавливать.

(92) Алгоритмы все в базе данных, тип индекса выбираешь ты при создании, как физически хранить и какой алгоритм использовать это прерогатива РСУБД. Так что твоё дело только USE THIS.

(93) Пусть использует GUID ( Уникальный идентификатор ) ничего страшного в binary(16) я лично не вижу. У тебя просто бэд сектор скорее всего образовался и тебе не повезло, вот и всё.

(94) Об том и речь! Нужно выбрать какой тип использовать разработчику Строку или УИД. Вы ваше мнение высказали. Хотелось бы услышать мнение SSSSS_AAAAA, и желательно с обоснованием.

(92) "Строка и для типа УИД"
Для сервера это просто два набора байт. Один из которых помечен как доступный для перекодировки (строка) и для вычисления длины набора надо учитывать возможную двухбайтовость кодировки, а второй - недоступен(бинари). ВСЁ! Больше между ними для сервера разницы нет. В индексе при поиске сравниваются наборы байт.

(97) а способы построения индексов от типа не зависят? Не будет ли в данной задаче индекс для УИДа эффективней чем индекс для Строки?

(96) Все вопросы по поиску лучшего способа для сферического запроса в сферической системе со сферической схемой хранения данных на сферическом сервере - полный идиотизм.

(98) Сколько раз надо повторить, что нет отдельных способов построения индексов для разных типов данных?

(92) Ты троллишь похоже. Ответ на твой вопрос давно дан. С точки зрения поиска по UID - все равно, что он в виде строки, что он в виде UUID. А если ты хочешь детального обоснования - извини, тут придется попыхтеть, почитать книжки, вникнуть в подробности. В двух словах не расскажешь.

(98) Откуда такая твердая уверенность, что UID - это нечто совершенно уникальное в части типов данных и для него просто обязано быть какое-то особенное построение индекса?

(102) УИД имеет четкую структуру и длину. Исходя из этого для него можно построить более эффективный индекс чем для других типов.

(103) Структура тут не причём, а так ату их, ату :)

(103) что может быть эффективнее сбалансированного дерева?

+(105) вам надо свою СУБД написать, со своими УИДАМИ и алгоритмами))

(105) Вот у тебя не уникальный индекс по строке - Name as string(100). Вот как тут использовать сбалансированное дерево?

(107) Да ещё 10 лямов записей

(104) Ну как же структура не причём? Возьмите например тип Дата, для него построение индекса ой как от структуры зависит. Причем разные индексы в зависимости от потребностей поиска.

(109) Дата это набор байтов и ничем не отличается от GUID, разве что размером

(110) Это так. И индекс для него это тоже набор байт. Но строится он по некоторым правилам и искать по нему быстрее чем по исходной таблице.

(103) Еще раз - для сервера это просто 16 байт без какой-либо структуры. Отсюда ваши рассуждения о возможности построения для него какого-то особенного индекса становятся измышлизамами.

(111) НЕТ для него особых правил.

(109) "тип Дата, для него построение индекса ой как от структуры зависит."
Где вы набрались такой чуши? С каких пор для двух байт понадобились структуры и особые индексы?

(114) Для булева индекса в Oracle к примеру есть Битовые индексы (bitmap indexes) http://oracle-dba.ru/docs/architecture/indexes

(107) как говорили товарищи выше: молча :)
с чем именно проблемы то? с уникальностью или сбалансированностью?

(114) Тип дата в разных системах храниться по разному. Поэтому ваше утверждение о двух байтах неверно.
А индексы нужны для быстрого поиска значений в базе данных. Поэтому для типа Дата может быть несколько вариантов индекса.
Но конечно, все они будут наборами байтов и серверу всё равно :-)

(116) Да пусть опишет как физически строится B-Tree индекс для строки?

(117) "Тип дата в разных системах храниться по разному."
Не просветите нас по этому вопросу? Назовите хоть пару систем с хранением даты в других форматах? И какие такие для них разные индексы можно построить?
"Но конечно, все они будут наборами байтов и серверу всё равно"
Именно.

(119) Вот для примера https://habrahabr.ru/post/69983/

(119) Как вы можете увидеть
•DATE — тип данных для хранения даты. Диапазон значений: 1000-01-01 — 9999-12-31. Занимает 3 байта.

(119) А вы на какую систему ориентируетесь?

(121) Забей в общем у индекса просто поле ключа будет иметь разную длину и в странице просто будет меньше ключей. Для строки я думаю всё же используется кэш и будет всё тот же использоваться тип индекса, с небольшими изменениями, если строка имеет длину в 100 байт, то на сравнениях будет большие потери, хотя не факт.

(121) Как вы можете увидеть в любом случае сервер оперирует именно наборами байт, представляющими из себя ЧИСЛО каких-то единиц времени до/от какой-то точки на шкале времени. Разница только в длине/разрядности числа.

(124) Только битами, битами управляет :) байт это уже высокоуровневая тема...

(119) Вы писали "И какие такие для них разные индексы можно построить?"
Тут ответ в прикладной задаче. Например:
1. Нужно выбрать все записи за 2015 год.
2. Нужно выбрать все записи за первое число всех месяцев всех лет.

Для первого случая подойдет индекс, построенный по части поля Год.
Для второго случая подойдет индекс, построенный по части поля Число.

Если использовать во второй задаче индекс от первой задачи, то эффективность такого поиска будет хуже чем просто сканирование таблицы.
Почувствуйте разницу.

(126) Для сервера в дате нет частей. Никаких.
Для конкретной прикладной задачи будут хранить не дату, а части даты в виде строк или чисел и по ним и будут делать индексы.
Почувствуйте разницу.

(126) Это дано на откуп тебе. В любом случае нужно из даты выносить либо год либо число и индексировать ( и индекс будет в данном случае по структуре одинаковым ). Для баз данных есть DBA и если построенные индексы разработчиков не удовлетворяют потребностям, у него всегда есть возможность повлиять на физическую сущность.

(127) (128) Ну это просто пример, который удобно рассматривать. Я хочу сказать, что для разных типов данных индекс будет строится по некоторым правилам, хотя бы по структуре хранения данных.

(127) Он весь твой :)

(129) Пошли отмазы про неудачно выбранный пример...
"для разных типов данных индекс будет строится"
Еще раз - где такой чуши набрались? Откуда уверенность, что именно так и будет? Структура у индексов одна и она не зависит от типа данных. Ибо она рассчитана изначально на хранение значений большинства известных серверу типов данных без учета смысла этих значений для конечного пользователя.

(131) Никаких отмазов. В условии автор спрашивает какой тип данных выбрать. А от этого зависит как будут данные храниться в базе и как построятся индексы. А от того как они построятся будет зависеть в конечном счете скорость поиска.

(132) Автор уже давно забил и запил, в крайнем случае перелогинься :)

(132) Он спросил всего лишь что быстрее работает поиска по ссылке или поиск по строке на 10 лямах, ну ясен пень что ссылка ( тем более кластер ) будет работать гораздо быстрее.

(132) "В условии автор спрашивает какой тип данных выбрать."
Уже написано, что для сферического и т.д. по тесту вопрос идиотский. Он перестанет быть таковым только после указания всех влияющих на выбор факторов.
"А от этого зависит как будут данные храниться в базе"
Это называется проектирование структуры и к индексам в этом деле относится только не/возможность проиндексировать какое-либо важное  для поиска поле.
" и как построятся индексы."
Не построятся. Если не дать соответствующую команду. И их структура будет зависеть от списка полей, а не от их типа.
"А от того как они построятся будет зависеть в конечном счете скорость поиска."
Построятся они одинаково - вырезкой указанных полей из таблицы. Без преобразований и без учета их типа.

Вы быть хоть что-то для чайников по базам почитали бы... Разработчиков СУБД за идиотов считаете? Не пробовали выяснить насколько ваши представления о БД, в общем, и о индексах, в частности, расходятся с теорией и практикой работы с базами данных?

(135) Некоторое представление о работе СУБД у меня есть и мне этого достаточно. То, что поиск по полям разных типов в прикладной системе происходит по разному я знаю точно ибо проверял не раз. И меня интересует в первую очередь результат в прикладной системе, а не то как там байты хранятся. Поэтому для меня решение данной задачи очевидно.
А с вами я не согласен. От типа данных зависит как данные хранятся в базе а значит зависят и индексы и производительность.

(136) "Некоторое представление о работе СУБД у меня есть и мне этого достаточно."
Ну, для вас и вашей работы может и достаточно, а вот для споров по узким и/или глубоким темам...
"Некоторое представление о работе СУБД у меня есть и мне этого достаточно. "
Потрясающе! Дилетант поставил свои дилетантские тесты и они теперь мерило всех баз данных... Сильный аргумент.
"И меня интересует в первую очередь результат в прикладной системе, а не то как там байты хранятся. "
Тем не менее именно про хранение вы нам тут много долго что-то пытались втирать...
" Поэтому для меня решение данной задачи очевидно. "
Какой задачи? Где и какую задачу то увидели?
"А с вами я не согласен."
Всё, от такого удара я сейчас сдохну... Несогласие со мной ТАКОГО спеца - невыносимо...
"От типа данных зависит как данные хранятся в базе а значит зависят и индексы и производительность."
Чуть вышек вы писали, что
"меня интересует в первую очередь результат в прикладной системе, а не то как там байты хранятся."
Вы уж определитесь...

Короче, аргументов и так было кот наплакал и потому пошли бездоказательные рассказы о собственно доблести.

(137) Вторая цитатка должна быть такой:
"поиск по полям разных типов в прикладной системе происходит по разному я знаю точно ибо проверял не раз."
И ей соответствует ответ про тесты.

(137)(138) Если вы тут не видите задачи, то откуда тут может быть спор по узким и/или глубоким темам?
А тем более интересно на каких основаниях вы сделали вывод о "дилетанте и дилетантских тестах"?
Я высказал свое мнение, основанное на моём опыте и защищаю свою позицию, делаю это корректно и не перехожу на личности. А вы ведете себя некорректно.

(138) В данном случае я думаю что тебе будет проще признать что ты не прав :) исходя из постов типа (139)

(140) тема с хэш-функцией строки в индексе выглядит не очень убедительно :)

(140) Я так не считаю.

(142) каким образом тогда будет работать покрывающий индекс? ведь фактически в этом случае нужен будет кей или рид лукап

(143) какое отношение ваш вопрос имеет к теме, которую мы обсуждаем?

(143) Если про like, то можно сделать первые 5,10 символов в качестве ключа и после подгрузи данных, сравнение уже с полной строкой... это уменьшит объём чтения, да и индекса. К примеру на строку в 250 символов.

(0) логически рассуждая, уид будет 16 байт, его строкоеое представление  72 байта
т.е. таблица будет больше размером, выборка будет больше
теоритически, строка будет менее производиельна

(145) речь не про лайк, а про то, как вытащить данные из индекса, который построен как хэш-функция от строкового поля, без обращения к самим данным. По-моему, это невозможно. А обращение к данным сведет на нет все преимущества хэширования.

(147) Вообще-то проблема не в выстаскивании 1 блока из тысячи, а в нахождении оного. Я не утверждаю что это так. Но хэш реально может ускорить и скорость не будет шибко зависить от длины строки.

(148) положим, тебе нужно выбрать фамилии всех сотрудников, есть индекс по фамилии. Если хэша нет, то все просто, достаточно сделать индекс скан и задача решена. А если в индексе лишь непонятный хэш? Скока тогда нужно будет сделать лишних действий и прочитать лишних страниц?

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

(149) Хэш к примеру на первые 5 байт. Далее поиск в данных

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