I all..
I have always used int(10) for everything, but couple days ago, I started a new project, and was hoping to do this 100% optimized ;)
So I am wondering, how many;
user_id => int(6) vs. mediumint (8) or similar will be possible to create/add
group_id => tinyint(1) vs tinyint (4) or similar will it be possible to create/add
and so on..
I know that the (X) is the width of the field, but, I can not quite understand the actual number of users/posts/messages ++ that can be created using example; mediumint(8) for id, instead of int(10).
Thanks for any reply on this!!
-Tom
Database IDs are usually always positive (0->∞) so the max value would be:
Integer Type Max Value
TINYINT 255
SMALLINT 65535
MEDIUMINT 16777215
INT 4294967295
BIGINT 18446744073709551615
I know that the (X) is the width of the field
The optional number in parens is the display width. It has nothing to do with how many unique values are in the range of the integer or how much storage space the integer needs. Application code is free to ignore your hint about the display width. "Display width" is a non-standard extension to SQL.
INTEGER(6) and INTEGER(2) both take 4 bytes to store, and both accept values ranging from -2147483648 to 2147483647.
All medium integers take 3 bytes to store, and accept values ranging from -8388608 to 8388607.
Assuming that a medium int is big enough (~ 16 million unique values) to identify your full domain of values you potentially save 1 byte per row over a 4-byte integer. (Potentially, because some platforms require padding to the next word boundary. For 32-bit systems, that would be 4 bytes, so no actual space savings. I don't know whether MySQL does that.) For 10 million rows, you might save 10 megabytes (plus some space savings in the index)--not very much these days. Narrower tables are generally faster than wider tables, but I don't think you'll notice the difference here.
Related
I am running a MySQL 5.7.30-0ubuntu0.16.04.1-log Server where I have the option of saving in char(4) or in smallint(5, unsigned).
There will be a primary index on the column and the key will be used as a referrence accross tables.
What is faster? Char or Int?
Unsigned SMALLINT values use two bytes and have values in the range [0, 65535]. CHAR(4) values take four bytes. So, indexing SMALLINT values will make for a smaller index. Smaller is faster. Plus indexes on character columns usually have all sorts of character-set and case-insensitivity monkey business built in to them, which also takes time and space.
But, for a table with at most 65K rows, the effect of this choice will be so small you'll have trouble measuring it. If you build something that's hard to debug, you'll spend your precious time and ten thousand times as much computer time debugging it than it will save.
Design your tables so they match your application. If you're using a four-digit number use SMALLINT.
The next person to work on your code (even if that person is you a year from now) will thank you for a clear implementation.
And keep in mind that MySQL ignores the number in parentheses on INT declarations. SMALLINT(4), SMALLINT(5), and SMALLINT all mean precisely the same thing. MySQL uses the native processor integer datatypes: TINYINT is an 8-bit number, SMALLINT a 16-bit number, INT a 32-bit number, and BIGINT a 64-bit number. Likewise FLOAT is a 32-bit IEEE 754 floating point number and DOUBLE a 64-bit one. The number of digits SMALLINT(4) is a nod to SQL standards compatibility.
As mentioned by O. Jones, SMALLINT will be faster and more space-efficient.
This is related to the following answer: mysql-char-vs-int
Also, MySQL Documentation:
CHAR and VARCHAR types
Integer Types
Case 1: The difference between CHAR(4) and SMALLINT is insignificant. It should not influence you choice of datatypes. Instead, use the datatypes that match the data.
Case 2: If you are comparing TINYINT to VARCHAR(255), the answer is probably different. Note that there is a much bigger difference in the choices.
Case 3: If the choice comes down to whether to "normalize" a column, there are arguments either way. I much prefer using a CHAR(2) for country_code than normalizing in order to shrink to a TINYINT. The overhead of extra normalization always(?) outweighs the space savings.
Another consideration: How many secondary keys are on the table? And how many other tables will you be joining to?
Case 4: PRIMARY KEY(big_string) but no secondary keys. There is no possibly no advantage in switching to an int.
Case 5: Since secondary keys include the PK, consider:
PRIMARY KEY(big_string),
INDEX(foo),
INDEX(bar)
versus
PRIMARY KEY(id), -- surrogate AUTO_INCREMENT
INDEX(big_string),
INDEX(foo),
INDEX(bar)
The latter will take less disk space.
Another consideration: Fetching a row is far more costly than comparing an int or string. My point is that you should not worry about comparison performance; you should look at the bigger picture when optimizing.
Case 6: USA 5-digit zip code. CHAR(5) (5 bytes) is reasonable. MEDIUMINT(5) UNSIGNED ZEROFILL (3 bytes) is better because it does everything better. (And it is a very rare case of the *INT(n) being meaningful.)
And the debate goes on and on.
I'm trying to increase database performance of one of my customers.
many tables have bigint(250). I've read on MySql documentation that the bigint is max 8 bits/bytes. I don't understand why it is possible to have a bigint(250) while the max is 8?
Also with the INT fields, some fields have INT(25), but INT is max 8 bit/bytes.
Do I see this correct or not?
And what does MySql with sizes that are bigger than the field size?
When dealing with types such as INT, BIGINT, etc,, the numbers inside the parentheses are for display width only, unlike e.g. VARCHAR where it defines the storage size as well.
If the display width is this big, you can safely assume the designer just had a moment of insanity, because unless the width is less than the maximum value, it's basically useless.
It would be more important to determine whether the field is signed. Defining it as BIGINT UNSIGNED effectively doubles the range for fields that should never be negative, such as an identifier.
As the question told, what if i want to have 256 numbers. Is this mean 256 as a number or byte? Because, i will definitely need more than 255
The 255 limit applys to a field with a type of byte, called a TinyInt in MySql. As the maximum value that can be represented in a single byte is 255.
An integer by default in MySql and most DBMS will be much larger than a single byte, in MySql it is 32bits, or 4 bytes long. This means it can store values from 0 to 4billion, or from -2billion to +2billion.
The official MySql reference for integer sizes is http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html
http://dev.mysql.com/doc/refman/5.5/en/numeric-types.html
"255" is a limitation of unsigned tinyint.
What 255 limit are you referring to?
This page on MySQL numeric datatypes clearly details the ranges available -- SMALLINT can hold between -32768 and 32767, INTEGER can hold a 32-bit signed integer value, etc.
The argument to any INT/BIGINT/MEDIUMINT/SMALLINT/TINYINT has nothing to do with the limit on its size or its range of values. It's just a hint for display width.
This is more useful if you use the ZEROFILL option for integer types. So it pads the value with zeroes. For example, storing 1234 into an INT(10) ZEROFILL column and fetching it back returns "0000001234". This makes some reporting look nicer. But the value stored in the database is just 1234.
The display width number doesn't make a TINYINT store any more or any less than 8 bits, no matter how large you make the width. Likewise SMALLINT is always 16 bits, MEDIUMINT is always 24 bits, INT is always 32 bits, and BIGINT is always 64 bits.
Nor does the display width constrain any of those types to store less than the full range of values permitted by their data type size. E.g. TINYINT(1) still allows all values -128 to 127.
The number arguments of NUMERIC or DECIMAL have a totally different meaning. They do determine the precision and scale of the data type, according to standard SQL.
Im new to Database programming and I have a very basic question:
In my PHPMyAdmin GUI that Im using to create tables in my database, what does it mean when the column "type" (ie. datatype) has the data type and something in brackets after that.
For example:
int(20), bigint(30) .....
I understand the type int and bigint imply the number of bytes that are used and consequently the range of values that can be stored. But what does the value in the brackets mean?
What does the (20) and the (30) stand for.... what impact does this have on....
Sorry if the Q is basic, I am trying to understand databases....
Thanks a lot
Basically this is a Display Width.
I've found very good explanation of this concept here is so decided to not describe it myself and let you read it yourself from the original source.
In the same way that a max-length can be specified for string data types (e.g. VARCHAR(5) = Maximum 5 Characters), Numeric data type cells can have a "Display Length" specified ( E.g.: INT(5) ).
There is a common misconception that specifying a Display Length on an INT column will limit that column's range. As example, it is quite often thought that defining a column as INT(1) will reduce the column's unsigned range to 0 - 9, and that INT(2) would reduce the column's unsigned range to 0 - 99. This is not the case. An INT data column will ALWAYS have a viable unsigned range of 0 - 4294967295, or a signed range of -2147483648 to 2147483647, irrespective of the specified Display Width, whether it be 1 ( INT(1) ) or 20 ( INT(20) ).
Display width doesn't change storage requirements for a data type.
Display width doesn't alter the actual data in any way (ie: it stores the entire value for the data)
A column returns it's full value when called in a query, regardless of the display width (the book directly contradicts this claim it makes as seen above)
The value in the bracket is the size or length of the field. [Edit strike]If set to 2 a uint field can only host values from 0 to 99.[/strike] You can set this value on your own and thus save a bit of memory if you expect your values not to exceed this limitation. Useful in connection with varchar.
Here another thread about varchar sizes: What are the optimum varchar sizes for MySQL?
Link to the mysql doc which explains it http://dev.mysql.com/doc/refman/5.7/en/numeric-type-attributes.html
I seem to see a lot of people arbitrarily assigning large sizes to primary/foreign key fields in their MySQL schemas, such as INT(11) and even BIGINT(20) as WordPress uses.
Now correct me if I'm wrong, but even an INT(4) would support (unsigned) values up to over 4 billion. Change it to INT(5) and you allow for values up to a quadrillion, which is more than you would ever need, unless possibly you're storing geodata at NASA/Google, which I'm sure most of us aren't.
Is there a reason people use such large sizes for their primary keys? Seems like a waste to me...
The size is neither bits nor bytes.
It's just the display width, that is
used when the field has ZEROFILL
specified.
and
INT[(M)] [UNSIGNED] [ZEROFILL] A
normal-size integer. The signed range
is -2147483648 to 2147483647. The
unsigned range is 0 to 4294967295.
See this explanation.
I don't see any good reason to use a number larger than 32-bit integer for indexing data in normal business-sized databases. Most of them have maybe millions of records (or that order of magnitude).