The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Какой тип индекса в mysql быстрее, CHAR или INT?"
Вариант для распечатки  
Пред. тема | След. тема 
Форум WEB технологии (MySQL)
Изначальное сообщение [ Отслеживать ]

"Какой тип индекса в mysql быстрее, CHAR или INT?"  +/
Сообщение от Игрек email on 04-Июл-12, 23:02 
Облазил весь интернет, нашел немного информации, только на английском.
Перечитал http://www.mysql.ru/docs/man/MySQL_indexes.html - там про это ничего не сказано.
Хочу поинтересоваться у знающих людей - какой тип PRIMARY KEY будет работать в mysql
быстрее с SELECT запросами: CHAR или INT? И почему?
Спасибо.
Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Какой тип индекса в mysql быстрее, CHAR или INT?"  +2 +/
Сообщение от DeadLoco (ok) on 05-Июл-12, 03:17 
> Хочу поинтересоваться у знающих людей - какой тип PRIMARY KEY будет работать
> в mysql быстрее с SELECT запросами: CHAR или INT? И почему?

ИНТ. Просто потому, что он всегда сравнивается в одну операцию. Строки сравниваются почарово, сначала первые чары, потом, если совпадают - вторые етц. Но сначала, разумеется, коллейшн. Если база наворочена в UTF8 (я гарантирую это), то вместо простого "<" дергается мультибайтное сравнение с промежуточным преобразованием в коллейшн, что шустрости тоже не прибавляет.

Любой индекс по чарам, а равно варчарам, как и по текстам, следует создавать только от тоски и безысходности. Это же касается полей типа DATETIME, которым всегда, если это возможно, следует предпочитать TIMESTAMP.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Какой тип индекса в mysql быстрее, CHAR или INT?"  +/
Сообщение от qwerty (??) on 26-Июл-12, 09:50 
О каких индексах идет речь? btree bitmap ??????
в некоторых случаях на больших наборах сильно разряженных данных стоит вобще отказаться от индекса, так как бд сначала бежит по индексу а затем по данным и то и то занимает одинаковое время. А по вашему вопросу индексы надо делать по тем полям который перечисляются в where, ну а если вам удалось заменить типы столбцов varchar или timestamp на int ну что же флаг вам в руки.  
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Какой тип индекса в mysql быстрее, CHAR или INT?"  +/
Сообщение от Игрек email on 26-Июл-12, 11:27 
Имелось в виду B-tree.
С ваших ответов понял, что лучше INT (так и думал, но надеялся на char...:) ), просто в поисках ответа отыскал сравнение:
http://dba.stackexchange.com/questions/15897/mysql-int-vs-va..., где не совсем разобравшись, решил лучше все-таки спросить специалистов.

P.S. Хотел использовать var/char-индексы для ЧПУ-URL - получается зря. (Есть и другие решения, просто так хотелось.)

DeadLoco и qwerty спасибо за помощь!

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Какой тип индекса в mysql быстрее, CHAR или INT?"  +/
Сообщение от LSTemp (ok) on 28-Июл-12, 03:52 
> Имелось в виду B-tree.
> С ваших ответов понял, что лучше INT (так и думал, но надеялся
> на char...:) ), просто в поисках ответа отыскал сравнение:
> http://dba.stackexchange.com/questions/15897/mysql-int-vs-va...,
> где не совсем разобравшись, решил лучше все-таки спросить специалистов.
> P.S. Хотел использовать var/char-индексы для ЧПУ-URL - получается зря. (Есть и другие
> решения, просто так хотелось.)

Вообще-то существует такая вещь, как нормализация БД. Никто не мешает Вам вынести первичный ключ ЧПУ-URL в отдельную таблицу и привязать к нему суррогатный ключ типа INT (по которому все связи в остальных таблицах строится и будут).


Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Какой тип индекса в mysql быстрее, CHAR или INT?"  +/
Сообщение от DeadLoco (ok) on 26-Июл-12, 13:02 
> так как бд сначала бежит по индексу а затем
> по данным и то и то занимает одинаковое время.

ЧОЧО?!

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

Если у вас БД без индексов работает быстрее, чем с индексами, то, вероятно, есть смысл сменить профессию.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Какой тип индекса в mysql быстрее, CHAR или INT?"  +/
Сообщение от LSTemp (ok) on 28-Июл-12, 03:48 
>> так как бд сначала бежит по индексу а затем
>> по данным и то и то занимает одинаковое время.
> ЧОЧО?!

ТОТО!
Зачем фразу из контекста выдернули?

> Учите матчасть.

И Вам того же.

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

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

> Если у вас БД без индексов работает быстрее, чем с индексами, то,
> вероятно, есть смысл сменить профессию.

Будете строить индекс по полю, где все возможные значения укладываются во множество {0,1,NULL} например? Если Вы такие индексы строите, то, вероятно, есть смысл сменить профессию.


Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Какой тип индекса в mysql быстрее, CHAR или INT?"  +/
Сообщение от DeadLoco (ok) on 28-Июл-12, 23:19 
> Будете строить индекс по полю, где все возможные значения укладываются во множество
> {0,1,NULL} например?

Я - нет. Но вот вышевысказавшийся оратор намекнул, что у него использование индексов снижает производительность СУБД. Почему, собсно, я и предложил задуматься о смене рода деятельности.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Какой тип индекса в mysql быстрее, CHAR или INT?"  +/
Сообщение от LSTemp (ok) on 29-Июл-12, 00:11 
>> Будете строить индекс по полю, где все возможные значения укладываются во множество
>> {0,1,NULL} например?
> Я - нет. Но вот вышевысказавшийся оратор намекнул, что у него использование
> индексов снижает производительность СУБД. Почему, собсно, я и предложил задуматься о
> смене рода деятельности.

Вы совершенно бессовестно в своем ответе порезали начало его ответа, где он вел речь о разреженных данных. И именно в этом контексте говорил, что возможно лучше от индекса в таком случае вообще отказаться. А теперь сами говорите, что никогда таких индексов не делаете. ИМХО я вижу в Ваших высказываниях явное противоречие.


Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Какой тип индекса в mysql быстрее, CHAR или INT?"  +/
Сообщение от DeadLoco (ok) on 29-Июл-12, 01:51 
> Вы совершенно бессовестно в своем ответе порезали начало его ответа, где он
> вел речь о разреженных данных. И именно в этом контексте говорил,
> что возможно лучше от индекса в таком случае вообще отказаться.

Фух, это, наверное, магнитные бури какие-то.

Нет в мускле никаких "разреженных данных". Нетути. Есть понятие кардинальности ключа - отношение числа уникальных значений ключа к размеру таблицы К є ]0,1]. Чем выше кардинальность ключа, тем меньше строк соответствует запросу, тем меньше временные таблицы, тем меньше накладные расходы, тем выше скорость выполнения. Скорость выполнения зависит не от "разреженности таблиц", а от объемов промежуточных вычислений. Оптимайзер мускля автоматически и довольно эффективно выстраивает подзапросы в порядке убывания кардинальности, чтобы минимизировать размеры временных таблиц. На "разреженность данных" ему начхать, он про такое ни сном, ни духом.

Если девелупер в таблицу вставляет поле {0,1,NULL}, и строит по нему индекс, да еще потом по этому полю начинает искать, то это не "разреженные данные" - это разжиженные мозги. В таком случае не _отказываться_ следует от индекса, а не строить его изначально. Следует проектировать базу таким образом, чтобы поле с низкой кардинальностью не использовалось соло, а только в качестве финального аккорда в рефайне выборки по более подходящим полям. Потому что в противном случае боттлнек случится даже не по времени выполнения запроса, а по ОЗУ, в котором тупо не поместится временная таблица.

Как-то так, примерно. В любом случае вот это:
"..на больших наборах сильно разряженных данных стоит вобще отказаться от индекса, так как бд сначала бежит по индексу а затем по данным и то и то занимает одинаковое время.."
к нашей вселенной отношения не имеет.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Какой тип индекса в mysql быстрее, CHAR или INT?"  +/
Сообщение от LSTemp (ok) on 30-Июл-12, 00:41 
>> Вы совершенно бессовестно в своем ответе порезали начало его ответа, где он
>> вел речь о разреженных данных. И именно в этом контексте говорил,
>> что возможно лучше от индекса в таком случае вообще отказаться.
> Фух, это, наверное, магнитные бури какие-то.

наверное...

> Нет в мускле никаких "разреженных данных". Нетути.

это общее понятие для ВСЕХ реляционных БД. Вы мускул к ним не относите?

>Есть понятие кардинальности ключа -
> отношение числа уникальных значений ключа к размеру таблицы К є ]0,1].
> Чем выше кардинальность ключа, тем меньше строк соответствует запросу, тем меньше
> временные таблицы, тем меньше накладные расходы, тем выше скорость выполнения. Скорость
> выполнения зависит не от "разреженности таблиц", а от объемов промежуточных вычислений.
> Оптимайзер мускля автоматически и довольно эффективно выстраивает подзапросы в порядке
> убывания кардинальности, чтобы минимизировать размеры временных таблиц. На "разреженность
> данных" ему начхать, он про такое ни сном, ни духом.

угу  - все умные читать и цитировать, а понимать что читали не хотят:

1) отношение уникальных значений ключа к размеру талицы (цитирую Вас)
2) если в ключе возможно присутствие NULL-значений (читай - разреженные данные) и число записей в таблице велико, то прикиньте для себя "кардинальность" такого ключа. стоит его создавать?

> Если девелупер в таблицу вставляет поле {0,1,NULL}, и строит по нему индекс,
> да еще потом по этому полю начинает искать, то это не
> "разреженные данные" - это разжиженные мозги. В таком случае не _отказываться_
> следует от индекса, а не строить его изначально. Следует проектировать базу
> таким образом, чтобы поле с низкой кардинальностью не использовалось соло, а
> только в качестве финального аккорда в рефайне выборки по более подходящим
> полям. Потому что в противном случае боттлнек случится даже не по
> времени выполнения запроса, а по ОЗУ, в котором тупо не поместится
> временная таблица.

1)
индекс по значениям поля {0,1,NULL} Вы делать не станете (тут все очевидно - не зависимо от разреженности данных делать ключ с ограниченным количеством уникальных значений смысла не имеет), а по значениям {0-1000000,NULL}? Вот тут учитывать разреженность данных при создании индекса имеет смысл.

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

> Как-то так, примерно. В любом случае вот это:
> "..на больших наборах сильно разряженных данных стоит вобще отказаться от индекса, так
> как бд сначала бежит по индексу а затем по данным и
> то и то занимает одинаковое время
.."
> к нашей вселенной отношения не имеет.

Разве, что Вы в другой вселенной живете или понятие "разреженные данные" (что скорей всего) Вам просто не знакомо...

PS
1) считаю, что querty абсолютно прав
2) нахальные высказывания (без всякого повода) в отношении других участников форума, считаю сволочизмом
3) поскольку разговор уже не в заданную тему - закрываю ее для себя


Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру