前言
开发一个特定的项目，构建最优的数据库模式，建立最优化的数据库系统，比如冗余较小、结构合理，来满足各种用户的应用需求，是每个开发者、维护者应具备的技能。
一、命名规范
命名就尽可能的见名知意
1.库名规范
范例：
- ecshop 一个商城的数据库名
- wifi_ecshop 通过加前缀区别不同业务
- ecshop_20190429 加年月日用于做备份数据的标示
2.表名规范
范例：
- article 文章表
- jk_article 带有表前缀(jk_)的,通过加前缀来区分不同表名
- article_details 文章详情表 单词之间用下划线连接
- article_keyword_relation 文章和关键字的关系表
3.表字段的规范
范例：
- id 作为自增用于主键的序号
- title 文章标题字段
- category_id 用于和分类表（category）的主键（id）进行关联的字段
- create_time 单词间还是用下划线连接
三、选择合适的存储引擎
在选择存储引擎时，应根据应用特点选择合适的存储引擎，对于复杂的应用系统可以根 据实际情况选择多种存储引擎进行组合。
下面是常用存储引擎的适用环境。
MyISAM： 默认的 MySQL 插件式存储引擎。如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么选择这个存 储引擎是非常适合的。MyISAM 是在 Web、数据仓储和其他应用环境下最常使用的存储引擎 之一。
InnoDB： 用于事务处理应用程序，支持外键。如果应用对事务的完整性有比较高的 要求，在并发条件下要求数据的一致性，数据操作除了插入和查询以外，还包括很多的更新、 删除操作，那么 InnoDB 存储引擎应该是比较合适的选择。InnoDB 存储引擎除了有效地降低 由于删除和更新导致的锁定，还可以确保事务的完整提交（Commit）和回滚（Rollback）， 对于类似计费系统或者财务系统等对数据准确性要求比较高的系统，InnoDB 都是合适的选 择。
MEMORY：将所有数据保存在 RAM 中，在需要快速定位记录和其他类似数据的环境 下，可提供极快的访问。MEMORY 的缺陷是对表的大小有限制，太大的表无法 CACHE 在内 存中，其次是要确保表的数据可以恢复，数据库异常终止后表中的数据是可以恢复的。 MEMORY 表通常用于更新不太频繁的小表，用以快速得到访问结果。
MERGE：用于将一系列等同的 MyISAM 表以逻辑方式组合在一起，并作为一个对象 引用它们。MERGE 表的优点在于可以突破对单个 MyISAM 表大小的限制，并且通过将不同 的表分布在多个磁盘上，可以有效地改善MERGE表的访问效率。这对于诸如数据仓储等VLDB 环境十分适合。
四、选择合适的字符集
选择合适的字符集，无emoji使用utf8，有emoji使用utf8mb4无emoji使用utf8，有emoji使用utf8mb4
推荐阅读：再见乱码：5分钟读懂MySQL字符集设置
五、选择合适的数据类型
这里指的是数据列的数据类型，在选择合适的数据类型时，我们应尽量满足以下条件:
- 尽量选择小，简单的数据类型。
- 保持可读性。
- 尽量避免Null
- 我们尽可能选择小的数据类型，这样会有很多好处，比如服务端处理效率，传输等都会快些。
- 几个常见的数据类型设计
- 固定长度的数据最好选择char类型 比如：11位的手机号码、用户md5后的密码
- 用户年龄字段 最好选用tinyint,无符号0-255 足够使用
- 尽可能给每个字段准备默认值，最好不能为null
- 对于二进制多媒体数据，流水队列数据(如日志)，超大文本数据不要放在数据库字段中
六、添加合适的索引
-
命名简洁明确，可见idx_或_index作为前缀或后缀。
-
根据业务查询（SQL语句构造的where查询）添加索引
-
确定唯一记录的字段建立主键索引或唯一索引，否则添加普通索引
数据重复性高的不适合建立索引
七、遵循三范式设计
数据库设计对数据的存储性能、数据的操作都有很大的关系。为了避免不规范的数据库出现数据冗余，造成插入、删除、更新操作异常 的情况，就要满足一定的规范化要求。
1、第一范式 确保每列都是不可分割
第一范式是指设计数据表的时候，确保表中的每一列都是不可分割的数据，即同一列中不能有多个值
1.1. 如果一个商城的会员的数据如下。如果我要统计查询地址的城市数据，就很是麻烦
| id | name | address |
|---|---|---|
| 1 | 李四 | 广东省深圳市龙华区老围新村21栋 |
| 2 | 张三 | 湖南省永州市冷水滩区天明路404栋 |
改造成符合第一范式的设计
| id | name | province | city | area | address |
|---|---|---|---|---|---|
| 1 | 聂哥 | 广东省 | 深圳市 | 龙华区 | 老围新村21栋 |
| 2 | 张三 | 湖南省 | 永州市 | 冷水滩区 | 天明路404栋 |
1.2.一个用户表数据存储用户的联系电话，如下
| id | username | phone |
|---|---|---|
| 1 | 李四 | 18682395281 |
| 2 | 王五 | 18612341234,18612345678 |
改造成符合第一范式的设计,用户表拆成
用户主表
| id | username |
|---|---|
| 1 | 李四 |
| 1 | 王五 |
联系方式表
| user_id | phone |
|---|---|
| 1 | 18682395281 |
| 2 | 18612341234 |
| 3 | 18612345678 |
2.第二范式 确保表中的每列都和主键相关
首先要先满足第一范式，然后确保表中的数据要一定完全依赖主键，而不能只依赖主键的一部分（复合主键）。即非主键字段完全依赖主键，不能部分依赖。
雇员信息表
| employee | department | header |
|---|---|---|
| jack | 运营部 | 马云 |
| 张三 | 宇宙科技部 | 神仙 |
这个表设计问题：修改数据时可能发生不一致，如果让马化腾来接管运营部门，那就要修改多行数据来反映这个变化，这是很痛苦又是很容易出错的操作。另外如果没有雇员信息的话，就没有办法表示新建一个新部门。且如果我们删除了jack、和张三的记录，你发现就没有任何关于运营部的信息了
正确的设计如下
部门表
| id | department | header |
|---|---|---|
| 1 | 宇宙科技部 | 神仙 |
| 2 | 运营部 | 马云 |
雇员信息表
| id | employee | depart_id |
|---|---|---|
| 1 | jack | 2 |
| 1 | 张三 | 1 |
3、第三范式 确保每列都和主键列直接相关,而不是间接相关
数据表中的每一列数据都和主键直接相关，而不能间接相关
订单表
| orderno | member_id | member | member_phone |
|---|---|---|---|
| jd123 | 1 | 李四 | 18612345678 |
| jd321 | 2 | jack | 18682395280 |
订单表里有会员的手机号码、会员姓名字段，而这些字段并不会和订单编号直接相关，而是和会员编号直接接相关，会员编号和订单编号直接相关
符合第三范式的设计
订单表
| orderno | member_id |
|---|---|
| jd123 | 1 |
| jd321 | 2 |
会员表
| id | member | member_phone |
|---|---|---|
| 1 | 李四 | 18682395280 |
| 2 | jack | 18682391234 |
八、反范式设计
顾名思义，就是不按照范式设计。按照三范式设计可以减少数据的大量的冗余，但是也增加了表的数量以及关联查询次数，我们知道关联查询会使查询性能降低。
反范式设计就是根据业务需要，适当的冗余查询频率高的字段，有时候配合索引优化提高查询效率。
转载：https://blog.csdn.net/Jhym2007/article/details/101846100