MySQL复习要点

柔光的暖阳◎ 2024-05-24 13:05 84阅读 0赞

### *MySQL事务处理的特性* ###

1.  原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。
2.  一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。
3.  隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。
4.  持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。

### *事务的并发问题* ###

1.  脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据
2.  不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。
3.  幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表

![20190905225321390.png][]

### *索引* ###

索引是什么：索引是为了加快查找速度的一种数据结构。

索引的作用：高效查找数据。

索引的结构：MyISAM和InnoDB都是采用B+树作为数据结构。

下面是B+tree的建树过程

依次插入  
6 10 4 14 5 11 15 3 2 12 1 7 8 8 6 3 6 21 5 15 15 6 32 23 45 65 7 8 6 5

![2019090522535973.gif][]

虽说MyISAM与InnoDB的数据结构都是B+树，但是其实现方式缺截然不同，具体的索引实现详见博客：[https://blog.csdn.net/b\_x\_p/article/details/86434387][https_blog.csdn.net_b_x_p_article_details_86434387]

#### ***MYSQL******为什么最终要去选择B+TREE？*** ####

1、B+TREE是B TREE的变种，B TREE能解决的问题，B+TREE也能够解决（降低树的高度，增大节点存储数据量）

2、 B+TREE扫库和扫表能力更强，如果我们要根据索引去进行数据表的扫描，对B TREE进行扫描，需要把整棵树遍历一遍，而B+TREE只需要遍历他的所有叶子节点即可（叶子节点之间有引用）。

3、B+TREE磁盘读写能力更强，他的根节点和支节点不保存数据区，所有根节点和支节点同样大小的情况下，保存的关键字要比B TREE要多。而叶子节点不保存子节点引用。所以，B+TREE读写一次磁盘加载的关键字比B TREE更多。

4、B+TREE排序能力更强，如上面的图中可以看出，B+TREE天然具有排序功能。

5、B+TREE查询效率更加稳定，每次查询数据，查询IO次数一定是稳定的。当然这个每个人的理解都不同，因为在B TREE如果根节点命中直接返回，确实效率更高。

#### 什么情况适合建立索引： ####

*  表的主键和外键需要建立索引；
 *  数据量超过300的需要建立索引；
 *  经常出现在where字句中的字段；
 *  经常用于连接两张表的列；
 *  经常需要范围查找的列，因为索引已经排序，所以指定的范围是连续的；
 *  经常需要排列的列，理由同上；

#### 索引的缺点： ####

*  更新数据时需要对索引进行更新；
 *  索引需要占用一定的空间。

### *数据库优化的思路* ###

这个我借鉴了慕课上关于数据库优化的课程。

1.SQL语句优化

1）应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

2）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num=0

3）很多时候用 exists 代替 in 是一个好的选择

4）用Where子句替换HAVING 子句 因为HAVING 只会在检索出所有记录之后才对结果集进行过滤

2.索引优化

看上文索引

3.数据库结构优化

1）范式优化： 比如消除冗余（节省空间。。）

2）反范式优化：比如适当加冗余等（减少join）

3）拆分表： 分区将数据在物理上分隔开，不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。这样，当对这个表进行查询时，只需要在表分区中进行扫描，而不必进行全表扫描，明显缩短了查询时间，另外处于不同磁盘的分区也将对这个表的数据传输分散在不同的磁盘I/O，一个精心设置的分区可以将数据传输对磁盘I/O竞争均匀地分散开。对数据量大的时时表可采取此方法。可按月自动建表分区。

4）拆分其实又分垂直拆分和水平拆分： 案例： 简单购物系统暂设涉及如下表： 1.产品表（数据量10w，稳定） 2.订单表（数据量200w，且有增长趋势） 3.用户表 （数据量100w，且有增长趋势） 以mysql为例讲述下水平拆分和垂直拆分，mysql能容忍的数量级在百万静态数据可以到千万 垂直拆分：解决问题：表与表之间的io竞争 不解决问题：单表中数据量增长出现的压力 方案： 把产品表和用户表放到一个server上 订单表单独放到一个server上 水平拆分： 解决问题：单表中数据量增长出现的压力 不解决问题：表与表之间的io争夺

方案： 用户表通过性别拆分为男用户表和女用户表 订单表通过已完成和完成中拆分为已完成订单和未完成订单 产品表 未完成订单放一个server上 已完成订单表盒男用户表放一个server上 女用户表放一个server上(女的爱购物 哈哈)

4.服务器硬件优化

### *InnoDB存储引擎* ###

InnoDB是默认的事务型存储引擎，也是最重要，使用最广泛的存储引擎。在没有特殊情况下，一般优先使用InnoDB存储引擎。

#### 1、数据存储形式 ####

使用InnoDB时，会将数据表分为.frm 和 idb两个文件进行存储。

#### 2、锁的粒度 ####

InnoDB采用**MVCC(****多版本并发控制****)**来支持高并发，InnoDB实现了四个隔离级别，默认级别是REPETABLE READ，并通过间隙锁策略防止幻读的出现。它的锁粒度是行锁。【通过MVCC实现，MVCC在稍后会进行介绍】

#### 3、事务 ####

InnoDB是典型的事务型存储引擎，并且通过一些机制和工具，支持真正的热备份。

#### 4、数据的存储特点 ####

InnoDB表是基于聚簇索引(另一篇博客有介绍)建立的，聚簇索引对主键的查询有很高的性能，不过他的二级索引（非主键索引）必须包含主键列，索引其他的索引会很大。

### *MyISAM存储引擎* ###

#### 1、数据存储形式 ####

MyISAM采用的是索引与数据分离的形式，将数据保存在三个文件中.frm.MYD,.MYIs。

#### 2、锁的粒度 ####

MyISAM不支持行锁，所以读取时对表加上共享锁，在写入是对表加上排他锁。由于是对整张表加锁，相比InnoDB，在并发写入时效率很低。

#### 3、事务 ####

MyISAM不支持事务。

#### 4、数据的存储特点 ####

MyISAM是基于非聚簇索引进行存储的。

#### 5、其他 ####

MyISAM提供了大量的特性，包括全文索引，压缩，空间函数，延迟更新索引键等。

进行压缩后的表是不能进行修改的，但是压缩表可以极大减少磁盘占用空间，因此也可以减少磁盘IO，从而提供查询性能。

全文索引，是一种基于分词创建的索引，可以支持复杂的查询。

延迟更新索引键，不会将更新的索引数据立即写入到磁盘，而是会写到内存中的缓冲区中，只有在清除缓冲区时候才会将对应的索引写入磁盘，这种方式大大提升了写入性能。

[20190905225321390.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/24/27b7974cdd584a199e7284eaf718d114.png
[2019090522535973.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/24/83c958a76eb34c3380e843e6282ce42e.gif
[https_blog.csdn.net_b_x_p_article_details_86434387]: https://blog.csdn.net/b_x_p/article/details/86434387