一眼mysql之一:架构

mysql架构

逻辑架构

• 第一层大部分是连接处理,授权认证,安全等
• 第二层则是核心服务:查询解析,分析,优化,缓存和所有内置函数,所有跨存储引擎的功能都在这一层:存过过程,触发器,视图等
• 第三层包含了存储引擎,不同存储引擎之间不会相互通信,简单的响应上层服务器的请求而已

连接管理和安全性

• 简单的在服务器进程里面拥有一个线程,连接查询只会在这个单独的线程里面执行,不需要为每个新建的连接创建或销毁线程(连接池),
• 安全则是服务器进行认证,

优化和执行

• 解析查询,然后创建解析树,接着进行各种优化,包括重写查询,决定表的读取顺序,和选择合适的索引等,可以通过特殊的关键字提示优化器,影响决策过程,
• 优化器不关心使用的是某种引擎,但是引擎对查询是有影响的,所以在建表时就可以选择引擎
• 在解析查询之前,会先检查查询缓存,如果能命中,服务器就不执行了具体的查询过程了

并发控制

• 首先是两个层面的并发控制:服务器层和存储引擎层
• 读写锁:共享锁和排它锁,也可以说是写锁和读锁
  • 读锁共享,相互不堵塞,
  • 写锁排他,只有一个用户能同时执行写入,并防止他人写入同一资源

锁粒度

锁的粒度可以理解为锁所要锁住的东西的大小,大的用大锁,小的用小锁,锁之间也存在各种操作,带来的是系统的开销,所以锁也不是越大越好也不是越多越好,合适即可

• 首先是表锁,也就是锁住整张表,然后基本使用是在备份的时候锁住整张表来做备份
• 行级锁:可以最大程度的支持并发处理,最明显的引擎为innodb和xtradb

事务

• 事务的概念:ACID

  • 一致性,持久性,原子性,隔离性

• 事务的好处:最主要的是保证数据的一致性

• 隔离级别

  • READ UNCOMMITTED(未提交读):不同事务里面,可以读到别人还没提交的事务里面的值,造成的 结果是脏读
  • READ COMMITTED(提交读/不可重复读):就是在我这个事务里面只有我事务结束了,你才能读到我这个修改的内容,造成的结果是,可能相同事务里面两个读操作读到的数据不一致
  • REPEATABLE READ(可重复读):也就是说我在本次事务里面,相同的读操作是不会改变的(除非自己做出修改),造成的结果是幻读,也就是相邻两次读不一致(mvcc解决)
  • SERIALIZABLE(可串行化):通过强制事务串行执行,每次读的数据上面都加锁,只有接受没有并发和非常确保数据一致性的情况下采用

• 死锁:两个或多个事务在同一资源上相互占用,请求锁定对方占有的资源,恶性循环的现象

• 解决方案:部分或完全回滚其中一个事务,重新执行因死锁回滚的事务即可

• 事务日志:在一个小区域内顺序io,如果是改写操作,就会写两次,一次写日志(内存),一次写磁盘,两段式提交

• mvcc:保存数据在某个时间点的快照来实现的,(可以理解成每个事务都有自己专门的一张表,不会变的)

• innodb的mvcc实现:通过在每行记录后面保存两个隐藏的列来实现,两个列,一个保存了行的创建时间,一个保存行的过期时间,存的是版本号,每开始一个新的事务,版本号会自动递增,事务开始时间的系统版本号就是事务的版本号,用来和查询得到的每行记录的版本号进行比较,

mysql的存储引擎

• 1:innodb存储引擎:是默认事务型引擎,擅长处理大量短期事务,采用mvcc支持高并发,默认隔离级别是可重复的,通过间隙锁策略防止欢度的出现,

  • 间隙锁 : 不仅仅锁定查询设计的行,还会对索引中的间隙进行锁定,防止幻影行的插入
  • 基于聚簇索引建立的,但是二级索引比较包含主键

• 2 myisam存储引擎

  • 不支持事务和行级锁,但是支持全文索引,压缩,空间函数等,缺陷是崩溃后无法安全恢复,对于只读或者表比较小,可以忍受修复操作,可以使用
  • 存储:将数据文件和索引文件分成.MYD和.MYI为扩展名的两个文件内,默认只能处理256t数据

• 3:如何选择合适的引擎

  • 1:需要事务支持,Innodb或xtraDB是最好的,如果不需要事务,而且主要是select和insert操作,使用myisam
  • 2备份:如果需要在线热备份选择innodb
  • 3:崩溃恢复:选择innodb而不是myisam