1: Field type priority integer > date, time > enum, char > varchar > blob
Column characteristics analysis:
Integer: Fixed length, no country/region differences, no character set differences
The time is fixed in length, the operation is fast, and the space is saved. Considering the time zone, it is inconvenient to write sql where > '2005-10-12';
enum: The purpose of constraining the value, it is stored internally with an integer type, but when it is interrogated with char, it has to undergo the conversion of string and value internally.
Char fixed length, taking into account character set and (sorting) collation set
varchar, the indefinite length needs to consider the collation set during character set conversion and sorting, and the speed is slow.
text/Blob cannot use in-memory temporary table
Attachment: Regarding the choice of date/time, the master's clear opinion
http://www.xaprb.com/blog/2014/01/30/timestamps-in-mysql/
Do you store date or time values in MySQL?
Would you like to know how to avoid many possible types of pain, most of which you cannot even begin to imagine until you experience them in really fun ways?
Then this blog post is for you. Here is a complete set of rules for how you can avoid aforementioned pain:
- All date and time columns shall be
INT UNSIGNED NOT NULL, and shall store a Unix timestamp in UTC.
Enjoy all the spare time you’ll have to do actually useful things as a result.
Gender: Take utf8 as an example
char(1) , 3 word length bytes
enum('male','female'); // Internally converted to numbers for storage, an additional conversion process
tinyint() , // 0 1 2 // fixed length 1 byte.
2: Just enough, don't be generous (such as smallint, varchar(N))
Reason: Large fields waste memory and affect speed,
Take age as an example tinyintunsigned not null , it can store 255 years old, which is enough. 3 bytes were wasted with int
The contents stored in varchar(10) and varchar(300) are the same, but varchar(300) takes more memory during table join query
3: Try to avoid using NULL()
Reason: NULL is not good for indexing and should be marked with special bytes.
It actually takes up more space on the disk.
experiment:
You can create 2 tables with the same fields, one is allowed to be null, the other is not allowed to be Null, add 10,000 entries to each, and check the size of the index file. It can be found that the index of null is larger. (In mysql5.5, about Null has been optimized, and the size difference is no longer obvious)
In addition: null is not easy to query,
where column_name=null;
where column name !=null; no value can be found,
where the column name is null or is not null can be queried.
create table dictnn (
id int,
word varchar(14) not null default '',
key(word)
)engine myisam charset utf8;
create table dictyn (
id int,
word varchar(14),
key(word)
)engine myisam charset utf8;
alter table dictnn disable keys;
alter table dictyn disable keys;
insert into dictnn select id,if(id%2,word,'') fromdict limit 10000;
insert into dictyn select id,if(id%2,word,null)from dict limit 10000;
alert table dictnn enable keys;
alter table dictyn enable keys;
Description of the Enum column
1: The enum column is stored internally as an integer
2: The enum column is the fastest associated with the enum column
3: enum column is weaker than (var) char---when encountering the association with char, it needs to be converted. It takes time.
4: The advantage is that when the char is very long, the enum is still an integer fixed length.
When the amount of data queried is larger, the advantage of enum is more obvious.
5: enum is associated with char/varchar, because the conversion is slower than enum->enum, char->char,
But sometimes it is used in this way - that is, when the amount of data is particularly large, it can save IO.
test:
create table t2 (
id int,
gender enum('man','woman'),
key(gender)
)engine myisam charset utf8;
create table t3 (
id int,
gender char(5) not null default '',
key(gender)
)engine myisam charset utf8;
alter table t2 disable keys;
alter table t3 disable keys;
insert into t2 select id,if(id%2,'man','woman')from dict limit 10000;
insert into t3 select id,if(id%2,'man','woman')from dict limit 10000;
alter table t2 enable keys;
alter table t3 enable keys;
mysql> select count(*) from t2 as ta,t2 as tb where ta.gender=tb.gender
mysql> select count(*) from t3 as ta,t3 as tb where ta.gender=tb.gender
| column <----> column |
time |
| Enum<--->enum |
10.53 |
| Char<---->char |
24.65 |
| Enum<---->char |
18.22 |
If the advantage of the t2 table is not obvious, increase the gender column of t3, char(15), char(20)...
As the gender column of t3 becomes larger, the advantage of the t2 table is gradually obvious.
Reason----no matter how long the characters enumerated by enum('manmaman','womanwomanwoman') are, they are internally represented by integers, and the size of the data generated in the memory remains unchanged, while the char type is generated in the memory data is increasing.
Summary: enum and enum type associations are faster
Enum type saves IO