Использование String перечислений в MySQL - вопрос производительности - PullRequest
0 голосов
/ 09 января 2011

В настоящее время я использую перечисления как TINYINTs в базе данных MySQL.В моих таблицах есть несколько миллионов строк.Затем мы отображаем перечисления из TINYINT в строки в другом месте.

Я рассматриваю хранение этих перечислений как строк.Если строки проиндексированы правильно, кто-нибудь знает, как MySQL работает при запросе перечислений String вместо перечислений TINYINT?

Оцените помощь.Спасибо.

Ответы [ 4 ]

3 голосов
/ 09 марта 2012

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

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

Не используйте перечисления для ответов "да / нет" или "мужчина / женщина", поскольку числовые данные и справочная таблица занимают гораздо больше места, чем значение "бит" (0 или 1). Кроме того, не используйте числовые строки в определении перечисления, например, enum ("1", "0"), так как это сбивает с толку любого, кто смотрит на код и запрос (потому что сохранена таблица поиска: [0 => "1", 1 => "0"].

1 голос
/ 13 марта 2011

(Предполагается, что вы используете TINYINT и у вас есть справочная таблица) TINYINT работает быстрее, но вы можете столкнуться с некоторыми падениями производительности из-за объединений.

Мой совет, если ваши значения перечисления не изменятся (например, - типы Male, Female, yes без типов enums), используйте вместо этого поле MYSQL ENUM. Он хранится с использованием 1 байта (если значения перечисления меньше 255) и не нуждается в соединениях.

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

0 голосов
/ 09 января 2011
0 голосов
/ 09 января 2011

TINYINT (или INTEGER для этой цели) индексируется быстрее и дает лучшую производительность в режимах SORT или SELECT, чем VARCHAR или CHAR.

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


Редактировать 1 Подробнее

Похоже, меньше VARCHAR, а INTEGER имеет незначительную разницу в производительности при индексировании. Смотрите здесь http://forums.mysql.com/read.php?115,251611,252006#msg-252006

...