Интересно, есть ли какой-либо положительный эффект при использовании флага UNSIGNED при определении некоторого целочисленного поля в MySQL? Делает ли запрос быстрее или меньше базы данных? Или я должен только беспокоиться об этом, если меня беспокоит верхний предел?
Подписано или без знака в MySQL
Ответ 1
В соответствии с раздел 10.2 руководства MySQL 5.1:
В нестрогом режиме, когда значение вне диапазона назначается целочисленный столбец, MySQL сохраняет значение представляющих соответствующие конечная точка типа данных столбца ассортимент. Если вы храните 256 в TINYINT или столбца TINYINT UNSIGNED, MySQL магазины 127 или 255 соответственно. когда столбец с плавающей точкой или с фиксированной точкой присваивается значение, превышающее диапазон, подразумеваемый указанным (или по умолчанию) точность и масштаб, MySQL сохраняет значение, представляющее соответствующей конечной точке этого диапазона.
Поэтому использование UNSIGNED действительно необходимо, только если вас беспокоит верхняя граница. Кроме того, добавление UNSIGNED не влияет на размер столбца, как число представлено.
Ответ 2
Это не имеет значения, если вы не пытаетесь получить максимальную отдачу от своих значений и не нуждаетесь в отрицательных значениях.
Например, скажем, вы хотели сохранить 0-255.
Вы можете использовать tinyint, но только если вы используете его как unsigned.
Множество баз данных, которые я видел, люди не утруждают себя оптимизацией и заканчивают довольно большими таблицами, потому что они просто используют INTs все время.
Тем не менее, если вы говорите о int vs unsigned int, влияние на производительность или косвенный эффект вообще отсутствует.
С точки зрения стандартов, я всегда использую unsigned и использую только подписанные, когда знаю, что мне нужны отрицательные значения.
Ответ 3
Когда дело доходит до производительности или хранения, это абсолютно то же самое.
В качестве ОБЩЕГО ПРАВИЛА используйте то, что подходит вам лучше: если вам понадобятся только положительные значения, сохраните значения как UNSIGNED, иначе пусть это будет по умолчанию [SIGNED].
Одна проблема возникает, когда для столбца PRIMARY AUTOINCREMENT задано значение SIGNED: подсчет автоматически сгенерированных чисел начинается с 1 (не наименьшее отрицательное число), а возможные значения заканчиваются раньше, так как вы будете использовать только половина значений. Таким образом, в этом случае (столбец PRIMARY + AUTOINCREMENT) лучше хранить как НЕОПРЕДЕЛЕННЫЙ.
Ответ 4
Используйте unsigned, когда столбец предназначен только для размещения положительных чисел.
Это не повлияет на производительность ввода/вывода в столбце, так как оно будет занимать ровно столько же места.
Ответ 5
Это улучшит перепроизводство, предположим, если вы хотите найти количество < 50o.
Без "unsigned" : Процесс потока, так как поле количества является "int", и у вас есть индекс этого поля, MySQL будет определять диапазон от -2147483648 до 500, и он получит результат на основе этого диапазона.
С "unsigned" : Процесс потока, так как поле количества является "int" с "unsigned" , и у вас есть индекс этого поля, MySQL будет определять диапазон от 0 до 500, и он получит результат на основе этого диапазона.
Ответ 6
Здесь вы можете увидеть документацию по MySQL для диапазонов SIGNED или UNSIGNED INTs. Вы быстро заметите, что пол для 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
Ответ 7
Предупреждение, возникает проблема с Unsigned Int (UINT) и Entity Framework или ADO.NET. Это может быть проблема интеграции с MySql Connector версии 6.
По моему опыту, UInt читается как Long EF, что может вызвать некоторые проблемы с точностью, поскольку UInt не Long. Это может вызвать головную боль с кем-либо, не знакомым с проблемой.
Другие проблемы:
Проблема интеграции между EF и Mysql Connector 6