数据库设计：
三范式
1NF.做到每列不可拆分(确保原子性)
如: 中国北京 不行 中国 北京 更好些
2NF.确保一个表只做一件事情
如:学生信息表 就提供学生信息 不要加上啥女友 房子 父母之类的其他列 非要写上这些 再写一张扩张表就行了
3NF.在满足2NF,消除表中的传递依赖
A-->B B-->C 则A-->C 要消除C (追求空间最省)
如:id【A】 售价 数量【B】 总价【C】 -->可以消除总价(节省空间 但是要计算总结会消耗多余的时间)
反三范式(追求时间最省)
满足3NF的要求 但是实际开发时 为了满足一些用户的特殊需求 在开发时再重新加入冗余字段
名词解释：
我们在日常工作中经常会听到QPS/TPS这些名词，也会经常被别人问起说你的系统吞吐量有多大。这个问题从业务上来讲，可以理解为应用系统每秒钟最大能接受的用户访问量。或者每秒钟最大能处理的请求数；
QPS: 每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。
TPS：每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多。
并发量：系统能同时处理的请求数
RT：响应时间，处理一次请求所需要的平均处理时间
计算关系：
QPS = 并发量 / 平均响应时间
并发量 = QPS * 平均响应时间
影响数据库的因素：
1.SQL查询速度 2.服务器硬件 3.网卡流量 4.磁盘IO 5.大表和大事务
1.超高的QPS和TPS
风险：
效率低下的sql
2.大量的并发和超高的CPU使用率
风险：
大量的并发-->数据库连接数被占满(max_connections 默认100)
超高的CPU使用率-->因CPU资料耗尽而出现宕机
3.磁盘IO
风险:
性能突然下降(使用更快的磁盘设备)
其他大量消耗磁盘性能的计划任务(调整计划任务,做好磁盘维护)
4.网络流量
风险：
网卡IO被占满(1000Mb/8大约等于100MB)
如何避免无法连接数据库的情况：
1.减少从服务器的数量 2.进行分级缓存 3.避免使用"select *"进行查询 4.分离业务网络和服务器网络
大表:
1.会出现慢查询
2.建立索引需要很长时间
风险：
MySQL版本<5.5建立索引会锁表
MySQL版本>=5.5会引起主从延迟
大事务:
定义：运行时间比较场，操作的数据比较多的事务。
风险：
锁定太多的数据，造成大量的阻塞和锁超时。
回滚时所需时间比较长
执行时间长，容易造成主从延迟
CPU选择：
目前mysql不支持多cpu对同一sql进行并发处理
所以更好的cpu比更多cpu好—>cpu密集型
如果要提高系统吞吐量(web类应用)—> 更多cpu—>5.6以后的版本
研究：交换分区。
索引:
查看索引:
对系统性能进行测量，就称为MySQL基准测试。
