【原创】面试官:讲讲mysql表设计要注意啥

引言

近期因为复习了一下mysql的内容，有些心得。随手讲其中一部分知识，都是一些烟哥本身平时工做的总结以及经验。你们看完，其实能避开不少坑。并且不少问题，都是面试中实打实会问到的！
好比

OK，具体有下面这些问题

• 一、为何必定要设一个主键？
• 二、大家主键是用自增仍是UUID?
• 三、主键为何不推荐有业务含义?
• 四、表示枚举的字段为何不用enum类型？
• 五、货币字段用什么类型?
• 六、时间字段用什么类型?
• 七、为何不直接存储图片、音频、视频等大容量内容?
• 八、字段为何要定义为NOT NULL?

其实上面这些问题，我最先想法是，每一个问题均可以啰嗦出一篇文章。后来因为良心发现，烟哥就决定用一篇文章将这些问题都讲明白。
固然，我给的回答可能并不是标准答案，毕竟是本身的一些工做总结。各位读者有更好的回答，也欢迎交流！

这里我要说一下，我用mysql只用过innodb存储引擎，其余的引擎真没用过。所以个人回答，都是基于innodb存储引擎中的。

正文

问题1:为何必定要设一个主键？
回答:由于你不设主键的状况下，innodb也会帮你生成一个隐藏列，做为自增主键。因此啦，反正都要生成一个主键，那你还不如本身指定一个主键，在有些状况下，就能显式的用上主键索引，提升查询效率！

问题2:主键是用自增仍是UUID?
回答:确定答自增啊。innodb 中的主键是聚簇索引。若是主键是自增的，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。若是不是自增主键，那么可能会在中间插入，就会引起页的分裂，产生不少表碎片！。
上面那句话看不懂没事，大白话一句就是:用自增插入性能好！
另外，附一个测试表给大家，表名带uuid的就是用uuid做为主键。你们看一下就知道性能差距了:

如上图所示，当主键是UUID的时候，插入时间更长，并且占用空间更大！

额，你们千万不要忘了，当你回答自增主键后，想一下《自增主键用完该怎么办？》

ps：这个问题，你要是能把UUID讲出合理的理由也行。

问题3:主键为何不推荐有业务含义?
回答:有以下两个缘由

• (1)由于任何有业务含义的列都有改变的可能性,主键一旦带上了业务含义，那么主键就有可能发生变动。主键一旦发生变动，该数据在磁盘上的存储位置就会发生变动，有可能会引起页分裂，产生空间碎片。
• (2)带有业务含义的主键，不必定是顺序自增的。那么就会致使数据的插入顺序，并不能保证后面插入数据的主键必定比前面的数据大。若是出现了，后面插入数据的主键比前面的小，就有可能引起页分裂，产生空间碎片。

问题4:表示枚举的字段为何不用enum类型？
回答:在工做中表示枚举的字段，通常用tinyint类型。
那为何不用enum类型呢？下面两个缘由
(1)ENUM类型的ORDER BY操做效率低，须要额外操做
(2)若是枚举值是数值，有陷阱
举个例子，表结构以下

CREATE TABLE test (foobar ENUM('0', '1', '2'));

此时，你执行语句

mysql> INSERT INTO test VALUES (1);

查询出的结果为

就产生了一个坑爹的结果。
插入语句应该像下面这么写，插入的才是1

mysql> INSERT INTO test VALUES (`1`);

问题5:货币字段用什么类型?
回答:若是货币单位是分，能够用Int类型。若是坚持用元，用Decimal。
千万不要答float和double，由于float和double是以二进制存储的，因此有必定的偏差。
打个比方，你建一个列以下

CREATE TABLE `t` (
  `price` float(10,2) DEFAULT NULL,
) ENGINE=InnoDB DEFAULT CHARSET=utf8

而后insert给price列一个数据为1234567.23，你会发现显示出来的数据变为1234567.25，精度失准！

问题6:时间字段用什么类型?
回答:此题无固定答案，应结合本身项目背景来答！把理由讲清楚就行！
(1)varchar，若是用varchar类型来存时间，优势在于显示直观。可是坑的地方也是挺多的。好比，插入的数据没有校验，你可能某天就发现一条数据为2013111的数据，请问这是表明2013年1月11日，仍是2013年11月1日？
其次，作时间比较运算，你须要用STR_TO_DATE等函数将其转化为时间类型，你会发现这么写是没法命中索引的。数据量一大，是个坑！

(2)timestamp，该类型是四个字节的整数，它能表示的时间范围为1970-01-01 08:00:01到2038-01-19 11:14:07。2038年之后的时间，是没法用timestamp类型存储的。
可是它有一个优点，timestamp类型是带有时区信息的。一旦你系统中的时区发生改变，例如你修改了时区

SET TIME_ZONE = "america/new_york";

你会发现，项目中的该字段的值本身会发生变动。这个特性用来作一些国际化大项目，跨时区的应用时，特别注意！

(3)datetime，datetime储存占用8个字节，它存储的时间范围为1000-01-01 00:00:00 ~ 9999-12-31 23:59:59。显然，存储时间范围更大。可是它坑的地方在于，他存储的是时间绝对值，不带有时区信息。若是你改变数据库的时区，该项的值不会本身发生变动！

(4)bigint，也是8个字节，本身维护一个时间戳，表示范围比timestamp大多了，就是要本身维护，不大方便。

问题7:为何不直接存储图片、音频、视频等大容量内容?
回答:咱们在实际应用中，都是用HDFS来存储文件。而后mysql中，只存文件的存放路径。mysql中有两个字段类型被用来设计存放大容量文件，也就是text和blob类型。可是，咱们在生产中，基本不用这两个类型！
主要缘由有以下两点

• (1)Mysql内存临时表不支持TEXT、BLOB这样的大数据类型，若是查询中包含这样的数据，在排序等操做时，就不能使用内存临时表，必须使用磁盘临时表进行。致使查询效率缓慢
• (2)binlog内容太多。由于你数据内容比较大，就会形成binlog内容比较多。你们也知道，主从同步是靠binlog进行同步，binlog太大了，就会致使主从同步效率问题！

所以，不推荐使用text和blob类型！

问题8:字段为何要定义为NOT NULL?
回答:OK，这问题从两个角度来答
(1)索引性能很差

Mysql难以优化引用可空列查询，它会使索引、索引统计和值更加复杂。可空列须要更多的存储空间，还须要mysql内部进行特殊处理。可空列被索引后，每条记录都须要一个额外的字节，还能致使MYisam 中固定大小的索引变成可变大小的索引。
—— 出自《高性能mysql第二版》

(2)查询会出现一些不可预料的结果
这里举一个例子，你们就懂了。假设，表结构以下

create table table_2 (
     `id` INT (11) NOT NULL,
    name varchar(20) NOT NULL
)

表数据是这样的

id	name
1	孤独烟
3
5	肥朝
7

你执行语句

select count(name) from table_2;

你会发现结果为2，可是其实是有四条数据的！相似的查询问题，其实有不少，不一一列举。
记住，由于null列的存在，会出现不少出人意料的结果，从而浪费开发时间去排查Bug.

总结

但愿你们有所收获吧！