1，INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT
| 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 |
2，The DATE, DATETIME, and TIMESTAMP Types
The DATE type is used for values with a date part but no time part. MySQL retrieves and displays DATE values in'YYYY-MM-DD' format. The supported range is '1000-01-01' to '9999-12-31'.
The DATETIME type is used for values that contain both date and time parts. MySQL retrieves and displaysDATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to'9999-12-31 23:59:59'.
The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of'1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.
3，Char VS Varchar
CHAR should be used for storing fix length character strings. String values will be space/blank padded before stored on disk. If this type is used to store varibale length strings, it will waste a lot of disk space.
Currently VARCHAR behaves exactly the same as VARCHAR2. However, this type should not be used as it is reserved for future usage.
VARCHAR2 is used to store variable length character strings. The string value's length will be stored on disk with the value itself.
4,Varchar VS Text
A question I hear once in a while is "why not make all your textual columns TEXT instead of VARCHAR?" I've never heard a solid answer, so I decided to run a simple benchmark - the results are somewhat surprising.
I created two tables - identical except that one uses VARCHAR(255) and the other uses TEXT. In order to render the two indexes similar, I indexed the entire VARCHAR(255) column but only the first 255 characters of the TEXT column:
CREATE TABLE V (a varchar(255) NOT NULL, PRIMARY KEY (a)) ENGINE=MyISAM;
CREATE TABLE T (a text NOT NULL, PRIMARY KEY (a(255))) ENGINE=MyISAM;
There are reasons for VARCHAR(255) being better than TEXT. (Your test did not find one, as was pointed out.)
When a tmp table is needed for a SELECT, the first choice is to use MEMORY, which will be RAM-only, hence probably noticeably faster. (Second choice is MyISAM.) However, TEXT and BLOB are not allowed in MEMORY, so it can't use it. (There are other reasons why it might skip MEMORY.)
Note: I believe the above comment applies even for TINYTEXT, which is nearly identical to VARCHAR(255).
Prefix indexes are almost always bad for performance. And they have a gotcha -- In your example (with "PRIMARY KEY (a(255))"), you are enforcing that the first 255 bytes of 'a' are distinct. (Yes, that was quite ok for your test, but is usually 'wrong' in real life.)
VARCHAR(255) can hold 255 characters.
TINYTEXT can hold 255 bytes.
Note the subtle difference, especially when running with utf8. This means that the former may hold more stuff.
I then created 200000 random strings from the alphabet [A-Z,a-z,0-9]. Each string was between 50 and 255 characters long. I loaded that set of strings into both tables (same data set in each table).
Datafile and index file sizes were nearly the same for both tables (the TEXT table was only a few bytes larger). However, queries against these two tables were remarkably different in terms of speed:
SELECT SQL_NO_CACHE count(*) from TABLE_NAME where a LIKE "n%";
I ran 16 queries like this against both tables, using random characters for n. Again, the same 16 queries were run against both tables. Queries against the TEXT table were always 3 times slower than those against the VARCHAR table (averages: 0.10 seconds for the VARCHAR table, 0.29 seconds for the TEXT table). The difference is 100% repeatable.