国庆期间复习了下Mysql和redis，ES包括：
Mysql索引面试题目分析
Mysql慢查询
Mysql表锁：共享读锁，独占写锁
? ? ??
结论：读锁会阻塞写，但是不会堵塞读。而写锁则会把读和写都堵塞。
表锁-读锁： 加读锁 lock table user read;
解锁 lock tables;
session1 session2 修改session1锁住的表 失败 阻塞 读session1锁住的表 成功 成功 修改session1没锁的表 失败 成功 读session1没锁的表 失败 成功
表锁-写锁： 加写锁 lock table user write;
解锁 lock tables;
session1 session2 修改session1锁住的表 成功 阻塞 读session1锁住的表 成功 阻塞 修改session1没锁的表 失败 成功 读session1没锁的表 失败 成功 ?查看哪些表被锁住了：
Mysql行级锁
?如何锁定一行：
Mysql主从复制:
都是一些配置的问题
基本原理：
复制的基本原则：
每个slave只有一个master
每个slave只能有一个唯一的服务器ID
每个master可以有多个salve
使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈
?? ???
Mysql的执行流程
Mysql的三大范式：
?? ??? ?1NF 原子性：表中每列不可再拆分。?
?? ??? ?2NF 不产生局部依赖，一张表只描述一件事情 // 第二范式就是在第一范式的基础上所有列完全依赖于主键列。
?? ??? ?3NF 不产生传递依赖，表中每一列都直接依赖于主键。而不是通过其它列间接依赖于主键。//简而言之，第三范式就是所有列不依赖于其它非主键列，也就是在满足2NF的基础上，任何非主列不得传递依赖于主键。所谓传递依赖，指的是如果存在"A → B → C"的决定关系，则C传递依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：主键列 → 非主键列x → 非主键列y // 存在传递的决定关系： 学号->所在学院 -> 学院地点?
redis的用途，以及与mysql的对比
在分布式数据库中CAP原理CAP+BASE：
C：Consistency（强一致性）
A：Availability（可用性）
P：Partion tolerance（分区容错性）
CAP的理论就是说在分布式存储系统中，最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这一点。
C：强一致性 A：高可用性 P：分布式容错性
CA 传统Oracle数据库
AP大多数网站架构的选择
CP Redis、Mongodb
?悲观锁：
顾名思义，每次去拿数据的时候都被认为别人会修改，所以每次在拿数据的时候都会被锁上，这样别人想拿这个数据就会block直到它拿到锁，传统的关系型数据库里边就用到了很多这种锁机制，比如行锁、表锁等，读锁、写锁等，都是在做操作之前先锁上。
乐观锁：
每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多度的应用类型，这样可以提高吞吐量。
乐观锁策略：提交版本必须大于记录当前版本才能执行更新。
?CAS：
redis事务
DISCARD：取消事务，放弃执行事务块内的所有命令。
EXEC：执行所有事务块的命令。
MULTI：标记一个事务块的开始。
UNWATCH：取消WATCH命令对多有key的监视。
WATCH key [key......]：监视一个（或多个）key，如果在事务执行之前这个key被其他命令所改动，那么事务将打断。
Case1：正常放行
Case2：放弃事务
Case3：全体连坐
Case4：冤头债主
Case5：watch监控
