MyCat 是基于服务器代理模式的数据库分库的中间件，原理是对 SQL 进行转发，具体的架构图如下：

我们知道，数据的拆分必然会对事物的原子性带来影响，那如果保证在分库的同时，又能保证事务的原子性呢？

对于分库分表来说，具体有两种方式：垂直拆分和水平拆分。
垂直拆分主要是业务的细化和独立，和业务联系比较密切。所以本文只讨论更通用的水平拆分。

为什么分库分表

1. 降低单机 MySQL 的性能
2. 降低单表或者单库的数据量，减少数据库的查询压力
3. 突破单机的容量限制

索引失效的情况：

1. 使用 like ‘%abc’或者like ‘%abc%’
2. 查询列参与了函数计算（并没有使用函数索引）
3. 数据不够离散，扫描的行数和加载索引的成本超过了全表扫描
4. 联合索引没有使用最左匹配，或者在范围运算（>,<,<>）等运算的后面
5. where中索引列有运算

除了上面的几个明显的问题外，还有索引的选择问题。MySQL 在执行一段 sql 的时候，会先决定使用哪一个索引，如果 选了一个性能比较差的索引，即使走了索引，也会带来性能问题。

对上面的第 4 条做一个例子说明：

1. 定义 abcd 字段一个联合索引
2. 如果使用 a>0 and b=1 .. 则 a 本身走索引，但 a 后面的字段都不走索引
3. a=1 and b=1 and c>1 and d=1 这个例子 只有 d 不走索引，如果 索引顺序更改为 abdc 则都会走索引。

为什么需要主从复制

1. 分别读写数据库的时候，把读和写分开，能够有效的提高数据库的负载
2. 保证数据的高可用，一旦有一台数据库服务器宕机，不会对数据产生太大的影响
3. 可以横向扩展，实现数据库的水平扩容

什么是事务日志？

事务要保证 ACID 的完整性必须依靠事务日志做跟踪：

1. 每一个操作在真正写入数据数据库之前，先写入到日志文件中

2. 如要删数据会先在日志文件中将此行标记为删除，但是数据库中的数据文件并没有发生变化。

3. 只有在（包含多个 sql 语句）整个事务提交后，再把整个事务中的 sql 语句批量同步到磁盘上的数据库文件。

4. 在事务引擎上的每一次写操作都需要执行两遍如下过程:

   • 先写入日志文件中

     写入日志文件中的仅仅是操作过程，而不是操作数据本身，所以速度比写数据库文件速度要快很多。

   • 然后再写入数据库文件中

     写入数据库文件的操作是重做事务日志中已提交的事务操作的记录

1. 下载包

   1	https://repo.huaweicloud.com/mysql/Downloads/MySQL-8.0/mysql-8.0.20-linux-glibc2.12-x86_64.tar.xz

2. 解压

   1 2 3 4

   $ tar -xvf mysql-8.0.20-linux-glibc2.12-x86_64.tar.xz # 移动到local/mysql目录下 $ sudo mv mysql-8.0.20-linux-glibc2.12-x86_64 /usr/local/mysql

上篇博客说了 MVCC 解决了 MySQL 在可重复的隔离情况下幻读的问题，这篇博客主要探讨下，在修改的时候，如何解决幻读的问题。

MySQL 在控制并发的时候，同样采用了锁的机制。从读写上面分，有读写和写锁，从结构上分，有行锁和表锁.行锁又分为行锁、间隙锁和 Next Key

读锁和写锁

读锁 ：共享锁 ，S 锁

写锁：排它锁 ，X 锁

select ：不加锁，加锁后，也可以使用 select 查询数据

数据库的事务一共有四个特性：

1. 原子性：代表事务是一个动作，要么同时成功，要么同时失败
2. 一致性：事务开始和结束数据完整性没有发生破坏
3. 隔离性：两个事务动作相互独立，不受干扰
4. 持久性：事务完成后，能够保存到数据库。

那 MySQL 是如何保证这个四个特性的呢？

为了弄明白这几个特性，我们需要先看下事务的隔离级别。

在不借助DB引擎情况下，想完成数据的持久化存储，最简单的方法写一个文件存在本地，读取的时候加载文件到内存，然后进行筛选。 存储一个user在本地。

1
2
3
4

id|userName|userCode|sex|phoneNumber
1,xiaoming,001,m,126xxx
2,xiaohong,002,w,123xxx
...

上面满足了我们的需求，看到这种数据格式，查询的时间复杂度为O(n).

B树和B+树是很多数据库索引采用的数据结构，为什么会使用B树，而不采用更常见的二叉树的呢？

举个例子,有这么几个数字：1,2,3,4,5,6,7,8,9,0,分别生成AVL树，B树