MySql学习笔记----MySql简介

一、前言

感谢小马哥从前端把我拉了出来，教会我很多知识，现在我要从0学习PHP，目前中正学习MySql，写博客是为了整理我的学习思路，以后我会持续不断的更新我的学习心得。

二、MySql相关知识

2.1 mysql逻辑架构

第一层：链接处理层

这一层是大多数软件都有的一层，本层主要处理授权认证，连接管理，安全性等问题

第二层：核心服务层

这一层主要做查询解析，分析，优化，缓存，以及内置函数调用。

第三层：存储引擎层

这一层主要是用存储引擎存储和读取数据。
MySql内部的搜索引擎包括：InnoDB，MyISAM,ArchiveBlackhole,CSV,Federated, Memory,Merge, NDB
后面我会详细介绍每一个搜索引擎，这里简单列一下。

第四层：数据层

所有的数据都在这里存放，供搜索引擎读取和存储。

2.2 mysql查询流程

mysql查询流程大体是这样的：
sql语句请求数据库 -> 缓存中有没有 -> 解析器 ->优化器(选取最优的搜索引擎) -> 搜索引擎 -> 数据读取

2.3 读写锁

大家知道对于并发如果不加上控制就有可能导致数据的混乱和毁坏，所以我们就有了并发控制的概念，在mysql中并发控制尤为重要.

2.3.1 读锁

读锁是共享的又叫共享锁。也就是说多个客户同时读取同一个数据是一点问题都没有的。

2.3.2 写锁

写锁又叫排他锁，根据名字我们就知道了，一个客户在写一个资源的时候会加锁，这个时候其他的客户不管是读还是写都会被堵塞。

2.4 锁粒度

要知道在加锁的时候会消耗资源的，比如：获得锁，检查锁，释放锁等等都会增加锁的开销。
如果锁太频繁了刚啥都不用干了光管理锁了，数据存取会降低。如果锁的不频繁，刚会导致大量请求语句被堵塞，存取速度会降低。所以我们需要一种好的策略来管理这些锁。

2.4.1表锁

对整个表的锁定。表锁非常霸道，当一个客户在对表写操作（增删改），会把整个表锁定，其他客户想读取这个表，没门，不行！
适应场景：适合大量读取数据而很少写数据的场景。

2.4.2 行锁

行锁顾名思义是对数据表中的一行进行加锁，相比于表锁能最大程度的支持并发，但是缺点也行明显：频繁的处理锁造成了大量的开销。
二种锁各有自己的适应场景，希望大家能灵活运用。

2.5 事务

事务就是一组原子操作的SQL语句。这么说可能大家不理解，这里我举例说明：
小马哥要把招行中200元钱转到农行中，那么步骤如下：

	1.检查招行中的钱是否高于200元
	2.从招行中减去200元
	3.在农行中增加200元

那么请大家想一下，如果第二步执行完了，但第三步执行失败会怎么样？后果就是小马哥的招行中少了200元，从但是农行中的钱没有增加。这就麻烦了！银行每天的流水何其庞大，这得吃多少官司。

所以事务内的语句要么全成功，要么全失败！
事务有如下特点：

1.原子性：一个事务被视为不能分隔的最小单位。事务中的操作要么全成功，要么全失败回滚，不允许只执行一部分，这就是原子性。
2.一致性：事务只有二个状态，即从一个状态转移到另外一个状态,不会出现一个中间状态。比如上面的例子招行少了200元，但农行中没有增加。
3.隔离性：一个事务在执行成功之前，对其他事务是不可见的。在上面的例子中，如果这三个步骤在执行中的过程中，在另外的提款机中查看招行中的钱是没有减去200元，农行中的钱是没有增加200元。
4.持久性：一但事务执行成功，会永久的存在了，即使系统崩溃，修改后的数据也不会丢失。

2.6 死锁

打个比方场景如下：

	小马哥吃饭时有个习惯：先拿筷子再拿碗才能吃饭。
	我吃饭时有个习惯：先拿碗再拿筷子才能吃饭。
	但是现在情况是摆在我俩面前只有一双筷子和一个碗，也就是说我们共用一双筷子，一个碗！

有趣的事情发生了：小马哥拿了筷子的同时我拿了一个碗。当小马哥再去拿碗的时候发现碗被我拿了(我对这个碗加锁了)。
当我去拿筷子的时候发现筷子被小马哥拿了。此时我俩谁都不释放手中的资源，导致我俩谁都无法吃饭。
这就是死锁：二个或多个事务在同一资源上占用，并要求锁定对方占用的资源，从而导致恶性循环。
我们公司平台以前非常卡，就是因为死锁导致大量的慢查询。

解决方法如下：
1.有人会说给多给碗筷不就不会这样了吗？的确是这样，创建大量的备份数据，但是这样成本也是非常昂贵的。
2.提前检测死锁的发生，如果检测到死锁立刻返回错误。
3.死锁等待超时立刻释放手中的资源，并且事务回滚，因为事务没有执行完，被强制释放资源了。

2.7 事务日志

事务日志能极大的提高事务的效率。为了提高存储速度，现在的存储引擎在修改表的时候只是修改表在内存中的拷贝，而不是把数据直接写进磁盘中。
这种方式虽然快但是隐患也是极大的，如果此时断电等不可抗力发生，这是非常致命的！我们的事务日志此时就发挥了非常好的作用，首先事务日志是在硬盘中持久保存的，每次修改内存中的数据的时候都会记录到事务日志中。如果此时断电，重新启动后，存储引擎会根据事务日志中的记录把数据慢慢刷回磁盘。

2.8 不要在事务中混用存储引擎

在同一个事务中使用多种存储引擎是不可靠的。
举个例子：如果在事务中混合使用了事务型和非事务型的表（比如InnoDB和MyISAM表），会出现什么问题呢？
要知道InnoDB是支持事务的，而MyISAM表是不支持事务的。
如果事务在执行的过程中中途出现问题，非事务表上的变更是无法撤销的，这就导致了数据库数据出现问题，这是很难修复的，而且执行的结果也是我们无法确定的，所以不要在事务中混用存储引擎。

2.9 MySql存储引擎介绍

InnoDB存储引擎

InnoDB是MySql最重要的存储引擎，没有之一。它是支持事务，在使用Mysql的时候优先考虑它，除非有非常特别的原因。

MyISAM存储引擎

1.MYISam存储引擎不支持事务和行级锁，相反MYISAM是表级锁。
2.最大的缺陷就是崩溃后无法安全恢复，这里指的是崩溃后修复可能有数据的丢失，而且修复特别慢。
适用于只读，表比较小等场景。

Archive 引擎

archive的意思是存档的意思，所以它仅仅支持插入和查询操作，
archive引擎适合日志和数据采集类的场合。

Memory引擎

如果需要快速的访问数据，而且允许一旦断电后数据的丢失，那么推荐使用Memory表。Memory表是在内存中工作的，速度非常快，MyISAM跟它简直不在一个等级上。

2.10 如何选择合适的引擎

选择引擎要考虑以下因素：

1.是否要支持事务
2.备份的需求也会影响存储引擎的选择。
3.崩溃后是否要完全恢复数据
4.其他特性。

每一种存储引擎都有各自的应用场合，要视情况而定。

三、结尾

好了就整理到这吧，加油！要坚持。