Home » Mysql » Signed or unsigned in MySQL

Signed or unsigned in MySQL

Posted by: admin November 1, 2017 Leave a comment

Questions:

I wonder is there any positive effect in using UNSIGNED flag on defining some integer field in MySQL? Does it make queries faster or database smaller? Or should I only bother with it if I’m concerned about upper limit?

Answers:

According to section 10.2 of the MySQL 5.1 Manual:

In non-strict mode, when an
out-of-range value is assigned to an
integer column, MySQL stores the value
representing the corresponding
endpoint of the column data type
range. If you store 256 into a TINYINT
or TINYINT UNSIGNED column, MySQL
stores 127 or 255, respectively. When
a floating-point or fixed-point column
is assigned a value that exceeds the
range implied by the specified (or
default) precision and scale, MySQL
stores the value representing the
corresponding endpoint of that range.

So using UNSIGNED is really only necessary when you are concerned about the upper bound. Also adding UNSIGNED does not affect the size of the column just how the number is represented.

Questions:
Answers:

It doesn’t matter unless you are trying to get the most bang for your buck out of the values and don’t need negative values.

For instance, let’s say you wanted to store 0-255.

You could use a tinyint but only if you use it as unsigned.

Lots of the databases I’ve seen, people don’t bother optimizing like this and end up with some rather large tables because they just use INTs all the time.

Still, if you’re talking about int vs unsigned int, there is no performance affect or space effect at all.

From a standards standpoint, I always use unsigned and only use signed when I know I will need negative values.

Questions:
Answers:

When it comes to performance or storage, it is absolutely the same thing.

As a GENERAL RULE, use whichever fits better for you: if you will need only positive values, store values as UNSIGNED, otherwise, let it be the default [SIGNED].

One problem arises when a SIGNED value is set for a PRIMARY AUTOINCREMENT column: the counting of the auto-generated numbers begin with 1 (not the smallest negative number) and the possible values will end earlier, as you will use only a half of values. So in this case (PRIMARY + AUTOINCREMENT column) it is better to store as UNSIGNED.

Questions:
Answers:

Use unsigned when the column is only meant to contain positive numbers.

It will not affect any I/O performance on the column, as it will still take up exactly the same amount of space.

Questions:
Answers:

It will improve the peroformance, lets suppose if you want to search for quantity < 50o.

Without “unsigned”:
Process flow, since the quantity field is an “int” and you have an index of this field, MySQL will define the range as -2147483648 to 500 and it will get the result based on this range.

With “unsigned”:
Process flow, since the quantity field is an “int” with “unsigned” and you have an index of this field, MySQL will define the range as 0 to 500 and it will get the result based on this range.

Questions:
Answers:

Here you can see the MySQL documentation for the ranges of SIGNED vs. UNSIGNED INTs. You’ll quickly notice that the floor for an UNSIGNED INT is always 0, thus it can never be negative.

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

Questions:
Answers:

Warning, there is an issue with Unsigned Int (UINT) and Entity Framework or ADO.NET. It might involve an integration problem by MySql Connector version 6.

In my experience, UInt is read as Long by the EF, which could raise some precision issues, since UInt is not Long. It might cause headaches with anyone not familiar with the issue.

Other concerns:

Integration problem between EF and Mysql Connector 6

DBContext cannot use UINT

EF provider trouble with UINT