Должны ли вы точно указывать типы столбцов в MySQL?

Question

Когда я определяю столбцы в MySQL, я обычно использую int, varchar (255), текст и случайное перечисление для логического значения. Каковы преимущества точного определения типов столбцов вместо того, чтобы просто оставлять их по максимуму?

Например, поле пароля, закодированное как MD5, никогда не будет превышать 32 символа, поэтому есть ли ощутимый выигрыш в производительности от использования varchar (32) над varchar (255)?

Answer 1

Per инструкция , VARCHAR(N) заданной фактической длины занимает одинаковое количество места для любого N до 255, поэтому использование 32 не экономит места. Но есть преимущество в ясности и удобочитаемости вашей схемы при использовании типа, который наилучшим образом представляет, какими должны быть реальные данные.

Answer 2

Есть большая выгода, если вы можете иметь фиксированный размер строки. Тогда индексирование происходит очень быстро. Вам придется использовать фиксированные типы столбцов, такие как int и char (некоторого размера) для текста.

Если у вас все равно будет переменный размер строки, а в вашей таблице будет менее 100 тыс. Записей, вам не стоит сильно беспокоиться об оптимизации. Текст вместо varchar более гибкий.

Что касается проверки данных, я думаю, вы должны включить это в свой бизнес-код / ​​проверку.

Answer 3

Я согласен с тем, что говорит Клайд, но ваш пример пароля не особенно хорош. Поскольку сумма MD5 ВСЕГДА будет 32 символа, вы можете использовать CHAR (32) вместо VARCHAR (32), который во многих случаях будет быстрее / эффективнее.

Answer 4

Современные РСУБД на самом деле не дают более высокой производительности для столбца из 255 символов по сравнению со столбцом из 50 символов из-за ширины столбца.

На SQL Server я стараюсь указать свое имя, адрес и т. Д. Как NVarChar, чтобы при необходимости я мог интернационализироваться. У меня есть хранилище телефонных номеров, которое в США может хранить более 10 цифр.

Answer 5

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

Для типов символов я действительно не уверен, будет ли это иметь значение или нет, если вы контролируете как БД, так и код. Но рассмотрим разделение труда, при котором разработчик базы данных говорит разработчику программного обеспечения: «Эй, не позволяйте людям вводить более 100 символов в это поле, это было бы полной тратой». Вы реализуете это, устанавливая лимит, в котором, если это был varchar (255), люди вполне могут потратить впустую пространство.