[TOC]
1.命名规范
表名、字段名、索引名等都需要命名规范,可读性高(一办要求使用英文),
表名、字段名必须使用小写字母或者数据,禁止使用数字开头,禁止使用拼音,并且不使用英文缩写。
主键索引名为pk_字段名:唯一索引为uk_字段名:普通索引名则为:idx_字段名。
2.选择合适的字段类型
设计表式,我们需要选择合适的字段类型,比如:
。尽可能选择存储空间小的字段类型，就好像数字类型的，从 tinyint、smallint、int、bigint 从左往右开始选择。
。小数类型如金额，则选择 decimal ，禁止使用 float 和 double。
。如果存储的字符串长度几乎相等，使用 char 定长字符串类型。
。varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000 。
。如果存储的值太大，建议字段类型修改为 text ，同时抽出单独一张表，用主键与之对应。
。同一表中，所有 varchar 字段的长度加起来，不能大于 65535,如果有这样的需求，请使用 TEXT/LONGTEXT 类型
3.主键设计要合理
主键设计的话，最好不要与业务逻辑有所关联。有些业务上的字段，比如身份证，虽然是唯一的，一些开发者喜欢用它来做主键，但是不是很建议哈。主键最好是毫无意义的一串独立不重复的数字，比如 UUID ，又或者 Auto_increment 自增的主键，或者是雪花算法生成的主键等等。
4.选择合适的字段长度
我们在设计表的时候，需要充分考虑一个字段的长度，比如一个用户名字段(它的长度5~20个字符) ，你觉得应该设置多长呢? 可以考虑设置为 username varchar (32) 。字段长度一般设置为2的幂哈'(也就是 2的n 次方)。;
5.优先考虑逻辑删除，而不是物理删除
。物理删除: 把数据从硬盘中删除，可释放存储空间
。逻辑删除: 给数据添加一个字段，比如 is_deleted ，以标记该数据已经逻辑删除。
为什么推养用逻辑删除，不推荐物理删除呢?
。为什么不推荐使用物理删除，因为恢复数据很困难
。物理删除会使自增主键不再连续
。核心业务表 的数据不建议做物理删除，只适合做状态变更,
6.每个表都需要添加create_time 等通用字段
表必备一般来说，或具备这几个字段:
。id:主键，一个表必须得有主键，必须
。create_time: 创建时间，必须
。modifed_time/update_time: 修改时间，必须，更新记录时，需要更新它。
。version:数据记录的版本号，用于乐观锁，非必须
。remark: 数据记录备注，非必须
。modified_by:修改人，非必须
。creator: 创建人，非必须
7.一张表的字段不宜过多
我们建表的时候，要牢记，一张表的字段不宜过多哈，一般尽量不要超过20个字段。
如果一张表的字段过多，表中保存的数据可能就会很大，查询效率就会很低。因此，一张表不要设计太多字段哈，如果业务需求，实在需要很多字段，可以把一张大的表，拆成多张小的表，它们的主键相同即可。
当表的字段数非常多时，可以将表分成两张表，一张作为条件查询表，一张作为详细内容表(主要是为了性能考虑)。
8.尽可能使用not null 定义字段
如果没有特殊的理由，一般都建议将字段定义为 NOT NULL。
为什么呢?
。首先，NOT NULL 可以防止出现空指针问题
。其次， NULL 值存储也需要额外的空间的，它也会导致比较运算更为复杂，使优化器难以优化SQL。
。NULL 值有可能会导致索引失效
。如果将字段默认设置成一个空字符串或常量值并没有什么不同，且都不会影响到应用逻辑，那就可以将这个字段设置为 NOT NULL 。
9.设计表时，评估哪些字段需要加索引
首先，评估你的表数据量。如果你的表数据量只有一百几十行，就没有必要加索引。否则设计表的时候，如果有查询条件的字段，一般就需要建立索引。但是索引也不能滥用:
。索引也不要建得太多，一般单表索引个数不要超过5个。因为创建过多的索引，会降低写得速度。
。区分度不高的字段，不能加索引，如性别等
。索引创建完后，还是要注意避免索引失效的情况，如使用mysgl的内置函数，会导致索引失效的
。索引过多的话，可以通过联合索引的话方式来优化。然后的话，索引还有一些规则，如覆盖索引，最左匹配原则等等。
10.不需要严格遵守3NF，可以通过业务字段冗余减少表关联
什么是数据库三范式( 3NF )，大家是否还有印象吗?
。第一范式:对属性的原子性，要求属性具有原子性，不可再分解;
。第二范式:对记录的唯一性，要求记录有唯一标识，即实体的唯一性，即不存在部分依.赖;
。第三范式:对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有几余，即不存在传递依赖;
我们设计表及其字段之间的关系,应尽最满足第三范式。但是有时候，可以适当冗余，来提高效率。比如以下这张表
| 商品名称 | 商品型号 | 单价 | 数量 | 总金额 |
|---|
| 手机 | 华为 | 8000 | 5 | 40000 |
以上这张存放商品信息的基本表。 总金额 这个字段的存在，表明该表的设计不满足第三范式，因为 总金额 可以由 单价*数量 得到，说明 总金额 是冗余字段。但是，增加 总金额 这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
11.避免使用MySQL保留字
如果库名、表名、字段名等属性含有保留字时， SQL 语句必须用反引号来引用属性名称，这将使得SQL语句书写、SHELL脚本中变量的转义等变得非常复杂。
因此，我们一般避免使用 MySQL 保留字，如 select、interval、desc 等等
12.不搞外键关联，一般都在代码维护
什么是外键?
外键，也叫 FOREIGN KEY ，它是用于将两个表连接在一起的键。 FOREIGN KEY 是一个表中的一个字段(或字段集合)，它引用另一个表中的 PRIMARY KEY 。它是用来保证数据的一致性和完整性的。
阿里的 java 规范也有这么一条:
[强制]不得使用外键与级联，一切外键概念必须在应用层解决。
我们为什么不推荐使用外键呢 ?
使用外键存在性能问题、并发死锁问题、使用起来不方便等等。每次做 DELETE 或者 UPDATE 都必须考虑外键约束，会导致开发的时候很难受,测试数据造数据也不方便。还有一个场景不能使用外键，就是分库分表。
13.一般都选择INNODB存储引擎
建表是需要选择存储引擎的，我们一般都选择 INNODB 存储引擎，除非读写比率小于 1%,才考虑使用 MyISAM 。
有些小伙伴可能会有疑惑，不是还有 MEMORY 等其他存储引擎吗? 什么时候使用它呢?其实其他存储引擎一般除了都建议在 DBA 的指导下使用。
我们来复习一下这 MySQL 这三种存储引擎的对比区别吧:
| 特性 | INNODB | MyISAM | MEMORY |
|---|
| 事务安全 | 支持 | 无 | 无 |
| 存储限制 | 64TB | 有 | 有 |
| 空间使用 | 高 | 低 | 低 |
| 内存使用 | 高 | 低 | 高 |
| 插入数据速度 | 低 | 高 | 高 |
| 是否支持外键 | 支持 | 无 | 无 |
14.选择合适统一的字符集
数据库库、表、开发程序等都需要统一字符集，通常中英文环境用 utf8。
MySQL支持的字符集有 utf8、utf8mb4、GBK、latin1 等。
。utf8: 支持中英文混合场景，国际通过，3个字节长度。utf8mb4: 完全兼容。
。utf8，4个字节长度，一般存储emoii表情需要用到它GBK: 支持中文，但是不
。支持国际通用字符集，2个字节长度。latin1: MySQL默认字符集，1个字节长度
15.如果你的数据库字段是枚举,需要在comment注释清楚
16.时间的类型选择
我们设计表的时候，一般都需要加通用时间的字段，如 create_time、modified_time 等等。
对于MySOL来说，主要有 date、datetime、time、timestamp 和 year
。date:表示的日期值,格式 yyyy-mm-dd,范围 1000-01-01 到 9999-12-31，3字节
。time:表示的时间值，格式 hh:mm:ss ，范围 -838:59:59 到 838:59:59 ，3字节
。datetime: 表示的日期时间值，格式 yyyy-mm-dd hh:mm:ss ，范围 1000-01-01 00:00:00到9999-12-3123:59:59“8字节，跟时区无关
。timestamp(常用):表示的时间戳值，格式为 yyyymmddhhmmss ，范围1970-91-01 00:0:1到2038-01-19 03:14:07 ，4字节，跟时区有关
。year:年份值，格式为 yyyy 。范围 1901到2155 ，1字节
推荐优先使用 datetime 类型来保存日期和时间，因为存储范围更大，且跟时区无关
17.不建议使用存储过程，触发器
什么是存储过程
已预编译为一个可执行过程的一个或多个SQL语句。
什么是触发器
触发器，指一段代码，当触发某个事件时，自动执行这些代码。使用场景:
。可以通过数据库中的相关表实现级联更改。
。实时监控某张表中的某个字段的更改而需要做出相应的处理。
。例如可以生成某些业务的编号。
。注意不要滥用，否则会造成数据库及应用程序的维护困难。
对于MYSOL来说，存储过程、触发器等还不是很成熟， 并没有完善的出错记录处理，不建议使用。
18.1:N关系的设计
19.大字段
设计表的时候，我们尤其需要关注一些大字段，即占用较多存储空间的字段。比如用来记录用户评论的字段，又或者记录博客内容的字段，“议或者保存合同数据的字段。如果直接把表字段设计成text类型的话，就会浪费存储空间，查询效率也不好。
在MySQl中，这种方式保存的设计方案，其实是不太合理的。这种非常大的数据，可以保存到mongodb 中，然后，在业务表保存对应 mongodb 的 id 即可。
这种设计思想类似于，我们表字段保存图片时，为什么不是保存图片内容，而是直接保存图片url即可。
20.分表分库
