Signed or unsigned in MySQL

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?

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.

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.

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.

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.

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.

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

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

I prefer using UNSIGNED SMALLINT (or MEDIUMINT) over SIGNED INT. It saves 2 (or 1) bytes which gives sometime better performace on large datasets, particularly with indexed columns.