1.字段类型
1.1 整型
字段 | 字节 | 无符号取值范围 | 有符号取值范围 |
---|
TINYINT | 1 | 0-255 | -128 - 127 |
SMALLINT | 2 | 0 - 65535 | -2^15 (-32,768) 到 2^15 - 1 (32,767) |
MEDIUMINT | 3 | 0 - 16777215 | -8388608到8388607 |
INT | 4 | 0 - 4294967295 | -2^31 (-2,147,483,648) - 2^31 - 1 (2,147,483,647) |
BIGINT | 8 | 0 - 18446744073709551615 | -2^63 (-9223372036854775808) 到 2^63-1 (9223372036854775807) |
1.2 浮点数
浮点数类型的取值范围为 M(1~255)和 D(1~30,且不能大于 M-2
字段 | 字节 | 释义 | 无符号取值范围 | 有符号取值范围 |
---|
FLOAT | 4 | 单精度浮点数 | 0 - (1.175494351E-38,3.402823466E+38) | (-3.402823466E+38~-1.175494351E-38) - 0 - (1.175494351E-38,3.402823466351E+38) |
DOUBLE | 8 | 双精度浮点数 | | |
DECIMAl | M+2 | 高精度小数类型 | 随着M和D决定,DECIMAL(20,5) | |
慎用浮点数,原因在MySQL对浮点类型数据的存储方式存在坑
MySQL用4个字节存储FLOAT类型数据,用8个字节来存储DOUBLE类型数据。无论哪个,都是采用二进制的方式来进行存储的。比如9.625,用二进制来表达,就是1001.101,或者表达成1.001101×2^3。看到了吗?如果尾数不是0或5(比如9.624),你就无法用一个二进制数来精确表达。
怎么办呢?就只好在取值允许的范围内进行近似(四舍五入)。
DECIMAL可以避免丢失精度的问题
DECIMAL是把整数和小数分开存储,分别转为16进制数进行存储的。所以避免了转为2进制丢失精度的问题
1.3 字符串
字段 | 位数 | 最大存储 | 备注 |
---|
CHAR | 8 | 255 | 固定长度 |
VARCHAR | 8 | 65535 | 可变长度 |
TINYTEXT | 8 | 255 | 小文本 |
TEXT | 8 | 65535 | 文本格式 |
MEDIUMTEXT | 8 | 16777215 | 中等文本 |
LONGTEXT | 8 | 4294967295 | 长文本 |
ENUM | 1-2 | 65535 | 枚举类型 |
SET | 1-8 | 64 | 集合类型 |
1.4 日期和时间
字段 | 格式 | 范围 | 字节数 |
---|
YEAR | YYYY | 1901-2155 | 1 |
TIME | HH:MM:SS | -838:59:59~838:59:59 | 3 |
DATE | YYYY-MM-DD | 1000-01-01~9999-12-31 | 3 |
DATETIME | YYYY-MM-DD HH:MM:SS | 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59 | 8 |
TIMESTAMP | YYYY-MM-DD HH:MM:SS | 1970-01-01 00:00:01 UTC~ 2038-01-19 03:14:07 UTC | 4 |
2. 字段定义规范
2.1 如果存储的字符串长度几乎相等,使用char定长字符串类型
2.2 VARCHAR设置更小粒度
varchar是可变长字符串,不预先分配存储空间,长度不要超过5000,如果存储长度 大于此值,定义字段类型为 text,独立出来一张表,用主键来对应,避免影响其它字段索引效率
2.3 小数类型为decimal,禁止使用float和double
2.4 合适的字符存储长度,不但节约数据库表空间、节约索引存储,更重要的是提升检索速度。
2.5 主键索引名为pk_字段名;唯一索引名为uk_字段名;普通索引名则为idx_字段名
2.6 表达是与否概念的字段,必须使用 is_xxx 的方式命名,数据类型是 unsigned tinyint(1 表示是,0 表示否)