Mysql知识点2

6、主从复制

基于BinLog的Replication

• 速度快
• 从节点只读
• 异步复制
• 弱一致性（由于复制不一样步）
• master宕机，slaver不会自动升级成master

适用于价值不高的数据，如日志、帖子等。

https://www.jianshu.com/p/faf0127f1cb2

 

PXC

• 同步复制（真正意义上的同步） 
• 强一致性
• 任意节点读写
• 只支持InnoDB引擎
• 写入效率取决于最弱的那一台
• 全部表必须都有主键

适用于一致性要求较高的数据，如订单、帐户、财务。

首先客户端先发起一个事务，该事务先在本地执行，执行完成以后就要发起对事务的提交操做了。在提交以前须要将产生的复制写集广播出去，而后获取到一个全局的事务ID号，一并传送到另外一个节点上面。经过合并数据以后，发现没有冲突数据，执行apply_cd和commit_cb动做，不然就须要取消这次事务的操做。而当前server节点经过验证以后，执行提交操做，并返回OK，若是验证没经过，则执行回滚。固然在生产中至少要有3个节点的集群环境，若是其中一个节点没有验证经过，出现了数据冲突，那么此时采起的方式就是讲出现不一致的节点踢出集群环境，并且它本身会执行shutdown命令，自动关机。 

7、数据库三范式

第一范式：数据库表中任意字段都是单一属性的，不可再分。

好比某些数据库系统中须要用到“地址”这个属性，原本直接将“地址”属性设计成一个数据库表的字段就行。可是若是系统常常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性从新拆分为省份、城市、详细地址等多个部分进行存储。

第二范式：第二范式在第一范式的基础之上更进一层。第二范式须要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对复合主键而言）。

例若有表：

货物	供应商ID	供应商	价格	供应商地址
毛巾	01	世纪联华	10.0	星光道
牙刷	01	世纪联华	5.0	星光道
毛巾	02	十足	12.0	月光道

可知，这里的主键有货物和供应商ID，价格和两个主键都有关，但是供应商地址只和供应商ID有依赖关系。那么不符合第二范式，咱们能够将其修改成两张表：

供应商ID	供应商	供应商地址
01	世纪联华	星光道
02	十足	月光道

货物	供应商ID	价格
毛巾	01	10.0
牙刷	01	5.0
毛巾	01	12.0

这样就符合了第二范式要求的表内数据和表内主键彻底依赖的关系。

第三范式：第三范式须要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

好比在设计一个订单数据表的时候，能够将客户编号做为一个外键和订单表创建相应的关系。而不能够在订单表中添加关于客户其它信息（好比姓名、所属公司等）的字段。