数据库设计
- 关系型数据库建议在E-R模型的基础上，我们需要根据产品经理的设计策划，抽取出来模型与关系，制定出表结构，这是项目开始的第一步
- 在开发中有很多设计数据库的软件，常用的如power designer，db desinger等，这些软件可以直观的看到实体及实体间的关系
- 设计数据库，可能是由专门的数据库设计人员完成，也可能是由开发组成员完成，一般是项目经理带领组员来完成
- 现阶段不需要独立完成数据库设计，但是要注意积累一些这方面的经验
三范式
- 经过研究和对使用中问题的总结，对于设计数据库提出了一些规范，这些规范被称为范式(Normal Form)
- 目前有迹可寻的共有8种范式，一般需要遵守3范式即可
- 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。
- 第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
- 第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
E-R模型
- E表示entry，实体，设计实体就像定义一个类一样，指定从哪些方面描述对象，一个实体转换为数据库中的一个表
- R表示relationship，关系，关系描述两个实体之间的对应规则，关系的类型包括包括一对一、一对多、多对多
- 关系也是一种数据，需要通过一个字段存储在表中
- 实体A对实体B为1对1，则在表A或表B中创建一个字段，存储另一个表的主键值
数据库瓶颈
不管是 IO 瓶颈还是 CPU 瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载的活跃连接数的阈值。
在业务 Service 来看， 就是可用数据库连接少甚至无连接可用，接下来就可以想象了（并发量、吞吐量、崩溃）。
- IO 瓶颈：
- 第一种：磁盘读 IO 瓶颈，热点数据太多，数据库缓存放不下，每次查询会产生大量的 IO，降低查询速度→分库和垂直分表。
- 第二种：网络 IO 瓶颈，请求的数据太多，网络带宽不够→分库。
.
- CPU 瓶颈：
- 第一种：SQL 问题：如 SQL 中包含 join，group by，order by，非索引字段条件查询等，增加 CPU 运算的操作→SQL 优化，建立合适的索引，在业务 Service 层进行业务计算。
- 第二种：单表数据量太大，查询时扫描的行太多，SQL 效率低，增加 CPU 运算的操作→水平分表。
什么时候考虑分库分表
能不分就不分
并不是所有表都需要切分，主要还是看数据的增长速度。切分后在某种程度上提升了业务的复杂程度。不到万不得已不要轻易使用分库分表这个“大招”，避免“过度设计”和“过早优化”。
分库分表之前，先尽力做力所能及的优化：升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后，在考虑分库分表。
数据量过大，正常运维影响业务访问
这里的运维是指：
- 对数据库备份，如果单表太大，备份时需要大量的磁盘 IO 和网络 IO。
- 对一个很大的表做 DDL，MySQL会锁住整个表，这个时间会很长，这段时间业务不能访问此表，影响很大。
- 大表经常访问和更新，就更有可能出现锁等待。
随着业务发展，需要对某些字段垂直拆分
这里就不举例了，在实际业务中都可能会碰到，有些不经常访问或者更新频率低的字段应该从大表中分离出去。数据量快速增长
随着业务的快速发展，单表中的数据量会持续增长，当性能接近瓶颈时，就需要考虑水平切分，做分库分表了。
扩展阅读
58到家数据库30条军规解读 链接
