Как выбрать оптимизированные типы данных для столбцов [innodb specific]?

Я изучаю использование типов данных для баз данных.

Например:

  • Что лучше для электронной почты? varchar [100], char [100] или tinyint (шутки)
  • Что лучше для имени пользователя? следует ли использовать int, bigint или varchar? Объясните. Некоторые из моих друзей говорят, что если мы будем использовать int, bigint или другой цифровой тип данных, это будет лучше (facebook делает это). Например, u = 123400023 относится к пользователю 123400023, а не к пользователю = thenameoftheuser. Поскольку числа занимают меньше времени для извлечения.
  • Что лучше для телефонных номеров? Сообщения (как в блогах или объявлениях)? Или, может быть, даты (я использую datetime для этого)? возможно, некоторые из них проводят исследования, которые хотели бы поделиться.
  • Цена продукта (я использую десятичную (11,2), не знаю о вас, ребята)?
  • Или что-нибудь еще, что вы имеете в виду, например: "Я использую серийный тип данных для blablabla".

Почему я конкретно упоминаю innodb?

Если вы не используете таблицу InnoDB (см. главу 11, "Дополнительно" MySQL ", для получения дополнительной информации), CHARстолбцы быстрее доступны, чем VARCHAR.

У Inno db есть некоторая разница, которую я не знаю. Я прочитал, что из здесь.

ОТВЕТЫ

Ответ 1

Краткое описание:

(только мои мнения)

  • для адреса электронной почты - VARCHAR(255)
  • для имени пользователя - VARCHAR(100) или VARCHAR(255)
  • для id_username - используйте INT (если вы не планируете более 2 миллиардов пользователей в вашей системе)
  • номера телефонов - INT или VARCHAR или, возможно, CHAR (зависит от того, хотите ли вы сохранить форматирование)
  • Сообщения - TEXT
  • даты - DATE или DATETIME (обязательно укажите время для таких вещей, как сообщения или электронные письма).
  • деньги - DECIMAL(11,2)
  • misc - см. ниже

Что касается использования InnoDB, потому что VARCHAR должен быть быстрее, я бы не стал беспокоиться об этом или о скорости в целом. Используйте InnoDB, потому что вам нужно делать транзакции и/или вы хотите использовать ограничения внешнего ключа (FK) для целостности данных. Кроме того, InnoDB использует блокировку на уровне строк, тогда как MyISAM использует только блокировку уровня таблицы. Поэтому InnoDB может обрабатывать более высокие уровни concurrency лучше, чем MyISAM. Используйте MyISAM для использования полнотекстовых индексов и для немного меньших накладных расходов.

Что более важно для скорости, чем тип двигателя: поместите индексы в столбцы, которые нужно быстро найти. Всегда указывайте индексы в столбцах ID/PK, например, имя id_username, о котором я упоминал.

Подробнее:

Вот куча вопросов о типах данных MySQL и дизайне базы данных (предупреждение, больше, чем вы просили):

И пару вопросов о том, когда использовать движок InnoDB:

Я просто использую tinyint для почти всего (серьезно).

Изменить - как сохранить "сообщения:"

Ниже приведены некоторые ссылки с более подробной информацией, но здесь короткая версия. Для хранения "сообщений" вам нужно место для длинной текстовой строки. CHAR максимальная длина равна 255, так что не опция и, конечно, CHAR будут использовать неиспользуемые символы в сравнении с VARCHAR, которая является переменной длиной CHAR.

До MySQL 5.0.3 максимальная длина VARCHAR была 255, поэтому вы останетесь с TEXT. Однако в новых версиях MySQL вы можете использовать VARCHAR или TEXT. Выбор сводится к предпочтению, но есть несколько отличий. VARCHAR и TEXT максимальная длина теперь равна 65 535, но вы можете установить собственный макс на VARCHAR. Скажем, вы думаете, что ваши сообщения должны быть только 2000 max, вы можете установить VARCHAR(2000). Если вы каждый раз сталкиваетесь с лимитом, вы можете ALTER вы поместить таблицу позже и поднять ее до VARCHAR(3000). С другой стороны, TEXT сохраняет свои данные в BLOB (1). Я слышал, что могут быть различия в производительности между VARCHAR и TEXT, но я не видел никаких доказательств, поэтому вам может понадобиться изучить это больше, но вы всегда можете изменить эту мелочь в будущем.

Более того, поиск этого столбца "post" с использованием полнотекстового индекса вместо LIKE будет намного быстрее (2). Однако вам нужно использовать механизм MyISAM для использования полнотекстового индекса, потому что InnoDB не поддерживает его. В базе данных MySQL вы можете иметь гетерогенное сочетание движков для каждой таблицы, поэтому вам просто нужно, чтобы таблица "posts" использовала MyISAM. Однако, если вам абсолютно необходимы "сообщения" для использования InnoDB (для транзакций), установите триггер для обновления копии MyISAM вашей таблицы "posts" и используйте копию MyISAM для всех ваших полнотекстовых поисков.

Смотрите дно для некоторых полезных цитат.

(3) "Значения в столбцах VARCHAR: строки переменной длины. Длина может быть задано как значение от 0 до 255 до MySQL 5.0.3 и 0 до 65 535 в версиях 5.0.3 и более поздних версиях.

До MySQL 5.0.3, если вам нужны данные тип, для которого нет удалите, рассмотрите возможность использования BLOB или TEXT тип.

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

До MySQL 5.0.3 конечные пробелы удаляются из значений, когда они хранится в столбце VARCHAR; это означает, что пробелы также отсутствуют от полученных значений.

Наконец, вот отличный пост о плюсах и минусах VARCHAR по сравнению с TEXT. Это также говорит о проблеме производительности:

Ответ 2

Есть несколько подходов к вашему вопросу.

Из дизайна POV всегда лучше выбрать тип данных, который выражает количество, которое вы хотите наилучшим образом смоделировать. То есть, правильно задайте область данных и данные, чтобы в первую очередь не удалось сохранить незаконные данные в базе данных. Но это не то, где MySQL в первую очередь силен, и особенно не по умолчанию sql_mode (http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html). Если он работает для вас, попробуйте TRADITIONAL sql_mode, который является сокращением для многих желаемых флагов.

Из производительности POV вопрос совершенно другой. Например, в отношении хранения тел электронной почты вам может потребоваться прочитать http://www.mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb/, а затем подумать об этом.

Удаление избыточности и наличие коротких ключей может стать большой победой. Например, в проекте, который я видел, в таблице журналов хранится информация о HTTP-пользователе. Просто заменив каждую строку пользовательского агента в таблице журналов на числовой идентификатор строки пользовательского агента в справочной таблице, размер набора данных был значительно (более 60%) уменьшен. При анализе пользовательского агента и последующем хранении набора идентификаторов (операционная система, тип браузера, индекс версии) размер набора данных был уменьшен до 1% от исходного размера.

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

Например, все, что имеет идентификатор в имени и не является целым типом без знака, вероятно, является ошибкой (особенно в контексте innodb).

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

Например, все, что работает с денежными данными и не использует тип данных DECIMAL соответствующего размера, вероятно, неправильно делает математику (DECIMAL делает BCD, десятичную бумажную математику с правильной точностью и округлением, DOUBLE и FLOAT - нет).

Ответ 3

SQLyog имеет Рассчитать оптимальный тип данных, который помогает находить оптимальный тип данных на основе записей, вставленных в таблицу. Он использует

SELECT * FROM table_name` АНАЛИЗ ПРОЦЕДУРЫ (1, 10);

чтобы узнать оптимальный тип данных