MYSQL优化篇（下）

7 . 什么是MYSQL的读写分离，主从复制？什么是分库分表？

8 . 连接池的最大连接数如何确定？有何根据？

解答：

7：读写分离 主从复制：既然要读写分离  还要主从复制，那肯定得有两台服务器AB呀，于是乎我们把写操作全部在A中进行，而读操作全部从B操作即读写分离。而B的数据是根据A的日志binlog进行写入即B根据日志复制A数据（两者会建立一个长连接（TCP IO线程）用于日志传输，主机开启一个dumplog线程生成binlog日志，从机开启slave线程读取binlog进行回放操作达到数据一致的目的），具体建议大家学习下sharding-JDBC 保证一看就懂

分库分表：可分为水平拆分和垂直拆分两种方式 理解：

垂直拆分：对行数据进行垂直拆分：即某表假设有十个字段  将其拆分为两张5+5字段的表

有点类似于我们微服务项目拆分模块思想

水平拆分：对行数据进行水平分割：假设现有十条数据  五条存于A库  5条存于B库

就是把数据根据一定条件如ID或者时间分配存储到不同的数据库

8：键盘撑不住了稍微省略点写：

在不考虑磁盘IO 网络IO 线程阻塞 等情况下，结合计算机组成原理中CPU的执行过程可以得出：最大连接数等于总服务器CPU内核数时效率最高

但综合顺位考虑磁盘IO 网络IO的情况下  给出的推荐公式为：CPU内核书*2+磁盘数，若业务需求上存在大量线程阻塞的情况下则应该继续增大最大连接数来大概寻找一个合适值

作为男人，文章这么短是不可能滴~！给大家补充点基础理解：

一：并发事务问题理解：以下假设有A，B两个事务

1.脏读：B事务读取到了A事务已修改但未提交的数据，然后对数据进行了修改并写入数据库，而事务A出现问题回滚了则此时数据已经错误

解决：READ COMMITED 读已提交 理解：只读已经提交了的数据······就是这么简单的理解

2.不可重复读：B事务过程中需要对某表进行两次读取操作，两次读取操作的中间事务A对数据进行了修改导致B读取的数据出现不一致问题

解决：REPEATABLE TABLE（可重复读）理解：锁已读取行数据 即在我B事务对数据进行操作时候锁住了所有已读取的数据行不允许A事务进行修改操作，总结就是  ==>锁已读取

3.幻读：事务B准备对某表所有age=3的数据进行修改，在找到所有age=3的数据行准备进行修改时发生阻塞，此时事务A趁虚而入偷偷的新增了十条age=3的小朋友，事务B回头修改了所有自己读取到的age=3的数据行完事找老板说活干完了申请提前下班，老板打开数据库一看当场抄了事务B的鱿鱼然后A光荣上岗。

总结就是B读取某表数据筛选需要操作的数据行，在筛选完但未修改时事务B又对该表数据新增了修改。

解决：SERIALIZABLE（串行化）理解：锁表   B直接大手一挥：我要和某表约会谁也不许动它

四种隔离级别对应的锁，如何理解？

前置知识：很重要！！：相同隔离级别对不同的操作（读和改）所施加的锁是不同的！

想要理解这个问题，需要先理解MYSQL中各种锁的含义：

1行锁？好理解   比如上面提到的锁已读取，就是只锁行数据

2表锁？好理解   顾名思义 表级别的锁   事务B把某表带走约会 事务A连见某表都见不着

3共享锁？没听过？据小丁考证这货也可以叫 读锁      简单理解就是  ：事务AB均可对某数据进行加锁（共享锁）此时该数据只能进行读操作，所有改操作必须等待AB都取消了共享锁才可操作。

4更新锁？也称意向排它锁，这货是MYSQL自己内部使用的    简单来说就是预定：上面的共享锁是所有人都可以对数据进行加锁，要进行改操作还得等所有人释放锁   那不得把等着修改操作的某事物憋死？于是乎有了更新锁：当某数据被加上更新锁后其他事务将不允许再对改数据施加更新锁或排它锁，此时加上更新锁的意义主要是避免死锁问题为升级为排它锁做准备但数据被加上更新锁后  其他事务仍可有读操作

5排它锁？又没听过？据小丁又考证这货可以叫 写锁 最好理解的锁：排斥其他事务：只有当前持有该数据排它锁的事务才可对数据进行读写操作其他人一律不准动（不能加锁）

6间隙锁？又又没听过？理解：一条一条数据库锁太麻烦了    直接根据索引锁某范围内的多行数据

所以间隙锁其实就是行锁的一种，只不过它同时锁了多行

理解上述内容后相信下面的总结大家看一眼就理解了：

RU  ==> 读操作不加锁   增删加共享锁

RC ==>  读操作不加锁   增删改加共享锁

RR ==>  读操作时就加共享锁

SE ==>   读操作时加排它锁

再一点：RR到底能不能解决幻读问题？

取决于该事务是快照读还是当前读   若是快照读则不会出现幻读问题，具体实验建议大家直接搜其他兄弟的博客吧，小丁键盘拼多多买的又要冒烟了，下次见 OvO！