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.
Related
I'm using phpMyAdmin to create my table structures.
I can read from the documentation pages on MySQL about size limits for Integer Types:
MySQL Integer Types Reference
So here is where I'm getting a little confused with creating a column.
I want to create a column in the table: tbl_note_categories called notescounter
I don't foresee myself creating thousands of noteids in the tbl_notes with any specific categoryid. But I do believe I'd create hundreds of notes to each categoryid.
I'm at that point of choosing between: tinyint, smallint, mediumint.
According the documentation link above, I'm guessing smallint is my best choice.
So here's my confusion. PhpMyAdmin asks for a Length/Values parameter to be specified.
I'm going to make sure this new column (notescounter) is unsigned, giving me up to 65536.
Does that mean I need the Length/Values to be (5)?
I'm guessing Length is character length, but I'm not sure. (comparing to varchar)
No, this is a common misconception about MySQL. In fact, the "length" has no effect on the size of an integer or the range of values it can store.
TINYINT is always 8 bits and can store 28 distinct values.
SMALLINT is always 16 bits and can store 216 distinct values.
INT is always 32 bits and can store 232 distinct values.
BIGINT is always 64 bits and can store 264 distinct values.
There's also a MEDIUMINT, but the engineers who work on MySQL tell me MEDIUMINT always gets promoted to a 32-bit INT internally, so there's actually no benefit to using MEDIUMINT.
The length is only for display, and this only matters if you use the ZEROFILL option.
See an example in my answer to What is the difference (when being applied to my code) between INT(10) and INT(12)?
Yes, you want to specify a length of 5.
In MySQL, the "length" attribute on the integer types is optional. It's a MySQL extension which is non-standard).
When it is omitted from the column declaration, MySQL provides a default value. For a SMALLINT UNSIGNED, the default value is 5.
This value does NOT have any impact on the range of values that can be stored for an integer type. It specifies a "display length", which is returned in resultset metadata, which a client can choose to use or ignore.
http://dev.mysql.com/doc/refman/5.5/en/numeric-type-attributes.html
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.
I made a table for storing contact record of user of my website. It also contains a 10 digit mobile no.
Table structure is like this:
CREATE TABLE contact_user
(
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
contact INT(10)
)
Now the problem is that if I insert a 10 mobile no.(e.g.9595891256) using phpmyadmin into contact field it will insert some random value and shows a warning saying "data out of column range"
But if I insert a simple 10 digit no (e.g.4561327894) then it works well and no warning is shown.
SO please tell me what is the issue in inserting a mobile no in this column?
I am using mysql 5.1 on ubuntu 11.04 and also using phpmyadmin.
INT(10) does not mean a 10-digit number, it means an integer with a display width of 10 digits. Whether you put INT(2) or INT(10), MySQL still only stores an (unsigned, in this case) INT which has a maximum value of 4294967295.
You can use a BIGINT instead of INT to store it as a numeric. I wouldn't recommend this, however, because it won't allow for international numbers. If you are certain your application will only use US numbers, using BIGINT will save you 3 bytes per row over VARCHAR(10) -- if that sort of thing concerns you.
Since it is a phone number (and therefore you won't be doing numeric calculations against it), try using a VARCHAR(20). This allows you the ability to store international phone numbers properly, should that need arise.
The maximum value for an INT in MySQL is 2147483647 (or 4294967295 if unsigned), according to the MySQL documentation. If your value exceeds this limit, you integer will overflow, hence the not-that-random value.
Also, INT is not the best solution to store phone numbers. You might lose leading zeros if they are one or more. Also, international phone numbers start with a + sign. Consider using a VARCHAR. This will end up using more space in the database, but will provide more consistency.
It is because of the max size of type INT you need to use a different type to hold a number that large. Try using BIGINT.
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 always thought that the number in the parenthesis represented the field length?
However, I understand that is not always the case. Maybe it's a MySQL issue? Someone told me if I set a field to 9 characters long, I can add a value that's more than 9 characters but only the first 9 will be saved.
Example:
CREATE TABLE `person` (
id INT,
age INT(2)
);
If that's the case, shouldn't I select something like TINYINT instead of INT for age?
INT(2) will generate an INT with the minimum display width of 2:
MySQL supports an extension for optionally specifying the display width of integer data types in parentheses following the base keyword for the type. For example, INT(4) specifies an INT with a display width of four digits. This optional display width may be used by applications to display integer values having a width less than the width specified for the column by left-padding them with spaces. (That is, this width is present in the metadata returned with result sets. Whether it is used or not is up to the application.)
The display width does not constrain the range of values that can be stored in the column. Nor does it prevent values wider than the column display width from being displayed correctly. For example, a column specified as SMALLINT(3) has the usual SMALLINT range of -32768 to 32767, and values outside the range permitted by three digits are displayed in full using more than three digits.
this does not affect the range of possible values that can be stored in the field; neither is it the number of bytes used to store it. It seems to be only a recommendation for applications how to show the value, unless ZEROFILL is used (see the linked page).
A unsigned TINYINT (0...255) would probably do as well, unless cryopreservation takes a big step forward during the lifetime of your application.
That's the case for field types like vchar, but for numbers it represents the number of bytes which it uses to represent the number. An integer of two bytes means you can hold a number 2^16 - 1 (8 bits in a byte, so 16 total). If it's age, I figure you ought to be safe with two bytes. ;)