Форум PHP программистов > Cелективность в составном индексе

[ Поиск ] - [ Пользователи ] - [ Календарь ]

Полная Версия: Cелективность в составном индексе

Страницы: 1, 2

vasa_c

29.01.2014 - 10:27

Итак, продолжаем нашу викторину по вопросу чем KEY(`a`,`b`,`c`) отличается от KEY (`c`,`b`,`a`). Кто же даст правильный ответ, не прибегая к умным терминам, селективность, кординалити? Все подсказки были даны.

_____________
Блог ГО | Таблица символов Юникода | Графомания

GET

29.01.2014 - 10:50

vasa_c

А чего поле d забыл написать, из-за которго весь сыр бор?

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

T1grOK

29.01.2014 - 11:06

Цитата (Invis1ble @ 29.01.2014 - 02:29)

Цитата

Забудь про ENUM как за страшный сон. Бесполезный тип данных.

это еще почему?

Во первых, если нужно, что-то изменить придется лезть в БД. Во вторых ENUM плохо сочетается с другими типами данных давая не самую высокую производительность при выборках.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

Invis1ble

29.01.2014 - 11:12

Цитата

ENUM плохо сочетается с другими типами данных

можно подробней?

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

GET

29.01.2014 - 11:13

T1grOK

Цитата

Во первых, если нужно, что-то изменить придется лезть в БД.

это к неграмотному проектировщику вопросы, а не к БД

Цитата

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

Пруф в студию, он не чем не отличается от них для MySQL, только более конкретен и занимает меньше места.

ИМХО

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

Invis1ble

29.01.2014 - 11:17

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

Использую ENUM везде, где это уместно, и ни разу не сталкивался ни с какими проблемами. Может это конечно мне так везет, не знаю...

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

T1grOK

29.01.2014 - 11:21

Цитата (ABC @ 28.01.2014 - 22:57)

Вот ради этого я пост и создал. Хотя мой тест с таблицами по 100 тыс. этого не подтвердил.

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

Цитата (ABC @ 28.01.2014 - 22:57)

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

Если первый столбец поле d - varchar - с очень высокой селективностью. В моем случае 3 строчки на 100 тысяч. Тогда для второго столбца всего 3 строки на обработку, а для последующих вообще единственная. Т.е. материал с которым придется работать MySQL совсем мал, всего 3 строчки изначально.

Если первый столбец поле a - ENUM - с очень низкой селективностью. В моем случае ~50000 строк на 100 тысяч. Тогда вплоть до самого последнего столбца будет "ворочаться" тысячи строк.

Так и есть, во втором случае будет проверена значительная часть индекса.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

Invis1ble

29.01.2014 - 11:28

Цитата

речь не идет про синтетические тесты, у меня используется ENUM в реальных рабочих проектах.

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

GET

29.01.2014 - 11:35

Цитата

так что поверь на опыт людей

всегда рад, когда есть тому подтверждение, например:

http://ruseller.com/lessons.php?rub=28&id=692

Цитата

Используйте ENUM вместо VARCHAR

Столбцы типа ENUM очень компактные и быстрые. Они хранятся в базе данных как и TINYINT, но еще они могут содержать строчные значения. Такие особенности делают их отличными кандидатами для реализации определенных полей.

+ еще куча ссылок, где все советую именно так делать.

Цитата

Хотя ENUM и противоречит нормальным формам, но, как показывают тесты, он быстрее других способов.

http://oleyniknv.ru/int/section_2/page_1
...
http://www.internet-technologies.ru/articl...ticle_1697.html

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

T1grOK

29.01.2014 - 11:42

Цитата (Invis1ble @ 29.01.2014 - 07:17)

Использую ENUM везде, где это уместно, и ни разу не сталкивался ни с какими проблемами.

Попробуй сравнить производительность, если делать выборку ENUM & VARCHAR, ENUM & ENUM. Скорость может отличаться в несколько раз.
Сортировка ENUM это вообще отдельная тема, так как эта операция производится по внутреннему указателю, а не по значениям, то есть придется то ли заведомо вносить значения в ENUM поле в алфавитном порядке, то ли извращаться с применением FIELD().
И по поводу обновления ENUM полей, надуманным это не считаю. Придется давать привилегии на обновление структуры таблицы, чтоб изменить значения в ENUM поле.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

T1grOK

29.01.2014 - 11:52

Цитата (ABC @ 29.01.2014 - 07:35)

Я бы сказал очень определенных(избранных)....
Я на проекте отказался от enum(не спорю, что многое зависит от архитектуры приложения), при этом запросы к таблицам(а они не маленькие >34 млн. строк) ускорились в среднем на 8%.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

Invis1ble

29.01.2014 - 12:05

Цитата

Сортировка ENUM это вообще отдельная тема, так как эта операция производится по внутреннему указателю, а не по значениям

ну это как бы логично

Цитата

Попробуй сравнить производительность, если делать выборку ENUM & VARCHAR, ENUM & ENUM.

не понял, имеешь в виду юзать в where условия по этим полям? Если да, то у меня к сожалению нет таблиц с более, чем 1 enum-полем

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

vasa_c

29.01.2014 - 12:28

Ну, в примере, вместо ENUM куда лучше бы BOOL вписался. И изменить список вариантов для большой таблицы будет весьма небыстро.

_____________
Блог ГО | Таблица символов Юникода | Графомания

GET

29.01.2014 - 16:17

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

Все доходчиво расписано по 8 пунктам.

Статья на английском, гуглом читабельно. Также с удовольствием почитал комменты.

Читать статью

p.s. Итог, согласен с автором статьи, как и с любым из вас, прежде чем что-то использовать нужно подумать головой, а не Ж.

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

twin

29.01.2014 - 20:32

Позволите небольшой оффтоп?

Ребят, я с огромным интересом следил за топиком. И даже начал болеть и переживать за первенство в викторине от vasa_c

Но вот почему то все скатилось к ENUM...

Нет, статьи интересные, вопросов нет. Но вот почему то, когда вникаешь в такие диспуты, вспоминается астрономя. Особенно раздел про черные дыры. Сидят именитые, с кучей степеней и прочих регалий ученые мужи и рассуждают: а есть ли у черных дыр горизонт событий... И как он, этот горизонт, соответствует постулатам квантовой механики и не нарушает ли теорию относительности...

Вот скажите мне, человеку ~~недалекому~~ приземленному. Кто на практике сталкивался с проблемой ENUM. Только не так, как подавалось:

Я помню, что когда то, где то, давно-давно, было замечено, что он тормозит события на пару микросекунд.

Я про реальные проблемы.

Неужели у вас действительно больше нет проблем, чем искать черную кошку в темной комнате?

Если так, я просто вам завидую. Тут и без этого куча проблем...

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image

Быстрый ответ:

Здесь расположена полная версия этой страницы.