Подписано или неподписано в MySQL

Question

Интересно, есть ли положительный эффект в использовании флага UNSIGNED при определении какого-либо целочисленного поля в MySQL? Делает ли это запросы быстрее или база данных меньше? Или я должен беспокоиться об этом, только если меня беспокоит верхний предел?

Answer 1

Согласно разделу 10.2 Руководства MySQL 5.1:

В нестрогом режиме, когда значение вне диапазона присваивается целочисленный столбец, MySQL хранит значение представляя соответствующий конечная точка типа данных столбца спектр. Если вы храните 256 в TINYINT или TINYINT UNSIGNED столбец, MySQL магазины 127 или 255 соответственно. когда столбец с плавающей или фиксированной точкой присваивается значение, которое превышает диапазон, подразумеваемый указанным (или по умолчанию) точность и масштаб, MySQL хранит значение, представляющее соответствующая конечная точка этого диапазона.

Таким образом, использование UNSIGNED действительно необходимо, только если вы беспокоитесь о верхней границе. Кроме того, добавление UNSIGNED не влияет на размер столбца, только то, как число представляется .

Answer 2

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

Например, допустим, вы хотели сохранить 0-255.

Вы можете использовать tinyint, но только если вы используете его без знака.

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

Тем не менее, если вы говорите о int против unsigned int, то это никак не влияет на производительность или пробел.

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

Answer 3

Когда речь идет о производительности или хранении, это абсолютно то же самое.

Как ОБЩЕЕ ПРАВИЛО, используйте то, что подходит вам больше: если вам нужны только положительные значения, сохраняйте значения как UNSIGNED, в противном случае, пусть это будет значение по умолчанию [SIGNED].

Одна проблема возникает, когда для столбца PRIMARY AUTOINCREMENT установлено значение SIGNED: подсчет автоматически сгенерированных чисел начинается с 1 (не наименьшего отрицательного числа), а возможные значения заканчиваются раньше, поскольку вы будете использовать только половина значений. Поэтому в этом случае (столбец PRIMARY + AUTOINCREMENT) лучше хранить как UNSIGNED.

Answer 4

Используйте unsigned, если столбец должен содержать только положительные числа.

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

Answer 5

Это улучшит производительность, допустим, если вы хотите искать количество <50o. </p>

Без «без знака»: Поток процесса, поскольку поле количества имеет тип «int», и у вас есть индекс этого поля, MySQL определит диапазон от -2147483648 до 500 и получит результат на основе этого диапазона.

С «без знака»: Поток процесса, поскольку поле количества имеет тип «int» и «unsigned», и у вас есть индекс этого поля, MySQL определит диапазон от 0 до 500 и получит результат на основе этого диапазона.

Answer 6

Здесь вы можете увидеть документацию MySQL для диапазонов SIGNED и UNSIGNED INT. Вы быстро заметите, что минимальное значение для UNSIGNED INT всегда равно 0, поэтому оно никогда не может быть отрицательным.

Type    Storage Minimum Value   Maximum Value
        (Bytes) (Signed/Unsigned)   (Signed/Unsigned)
TINYINT     1   -128            127
                0               255
SMALLINT    2   -32768          32767
                0               65535
MEDIUMINT   3   -8388608        8388607
                0               16777215
INT         4   -2147483648     2147483647
                0               4294967295
BIGINT      8   -9223372036854775808    9223372036854775807
                0               18446744073709551615

Answer 7

Предупреждение , есть проблема с Unsigned Int (UINT) и Entity Framework или ADO.NET. Это может быть связано с проблемой интеграции с MySql Connector версии 6.

По моему опыту EF UInt читается как Long, что может вызвать некоторые проблемы с точностью, поскольку UInt не Long Это может вызвать головную боль у тех, кто не знаком с этой проблемой.

Другие проблемы:

Проблема интеграции между EF и Mysql Connector 6

DBContext не может использовать UINT

Проблема поставщика EF с UINT

Answer 8

Я предпочитаю использовать UNSIGNED SMALLINT (или MEDIUMINT), а не SIGNED INT. Это экономит 2 (или 1) байта , что дает иногда лучшую производительность на больших наборах данных, особенно с индексированными столбцами.