Mysql
MySQL是一个开放源代码的关系型数据库管理系统。
MySQL架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。
和其它数据库相比，MySQL有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。
Mysql架构
mysql是由Connection Pool连接池、SQL接口（SQL Interface）、解析器（Parser）、优化器（Optimizer）、查询缓存（Caches & Buffer）、存储引擎（Pluggable Storage Engines）组成。
部件介绍
1、Connectors：与客户端工具和其他编程语言的SQL语句进行交互，如java、php等。
2、Management Services & Uilities：系统管理和控制工具。
3、Connection Pool：管理和缓冲用户连接，线程处理等需要缓冲的需求，主要是连接处理、授权认证等，为通过认证的用户提供线程。也可以实现基于SSL的安全链接。
4、SQL Interface：接受用户的SQL命令，并且返回用户需要的结果。
5、Parser：验证和解析用户传递过来的SQL命令，将SQL语句分解成数据结构，并将这个结构传递到后续步骤。如果分解过程遇到SQL命令错误，将不会继续执行该语句，
6、Optimizer：对SQL语句进行优化，使用“选取-投影-联接”策略进行查询，优化会产生多种执行计划，最终使用最优的方案去执行。
用一个例子就可以理解： select uid,name from user where gender = 1;
这个select 查询先根据where 语句进行选取，而不是先将表全部查询出来以后再进行gender过滤
这个select查询先根据uid和name进行属性投影，而不是将属性全部取出以后再进行过滤
将这两个查询条件联接起来生成最终查询结果.
7、Caches & Buffer：如果查询缓存有命中的查询结果，查询语句直接去查询缓存中取数据，否则去执行执行计划。
8、Pluggable Storage Engines:存储引擎是MySql中具体的与文件打交道的子系统。也是Mysql最具有特色的一个地方。
Mysql的存储引擎是插件式的。它根据MySql AB公司提供的文件访问层的一个抽象接口来定制一种文件访问机制（这种文件访问机制就叫存储引擎）
Mysql逻辑架构整体分三层
最上层：客户连接服务层，是一些客户端和连接服务，包含本地的sock通信和大多数基于客户端/服务端工具实现的类似于tcp/ip的通信，主要完成一些类似于连接处理、授权认证及相关的安全方案，在该层上引用了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于ssl的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
第二层：mysql核心服务功能层，主要完成大多数的核心服务功能。如sql接口，并完成缓存的查询。sql的分析和优化 以及部分内置函数的执行。所有跨存储引擎的功能也在这一层实现，如过程，函数等。在该层，服务器会解析查询并创建相应的内部解析树，并对其完成相应的优化如确定查询表的顺序，是否利用索引等。最后生成相应的执行操作。如select语句，服务器还会查询内部的缓存。如果缓存空间足够大，这样就解决大量读操作的环境中能够很好的提升系统的性能。
最底层：存储引擎层，负责了MySQL中数据的存储和提取，服务器通过API与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取。
SQL语句执行过程
数据库通常不会被直接使用，而是由其他编程语言通过SQL语句调用mysql，由mysql处理并返回执行结果。那么Mysql接受到SQL语句后，又是如何处理的呢？
首先程序的请求会通过mysql的connectors与其进行交互，请求到处后，会暂时存放在连接池（connection pool)中并由处理器（Management Serveices & Utilities）管理。当该请求从等待队列进入到处理队列，管理器会将该请求丢给SQL接口（SQL Interface）。SQL接口接收到请求后，它会将请求进行hash处理并与缓存中的结果进行对比，如果完全匹配则通过缓存直接返回处理结果；否则，需要完整的走一趟流程：
(1)由SQL接口丢给后面的解释器（Parser），上面已经说到，解释器会判断SQL语句正确与否，若正确则将其转化为数据结构。
(2)解释器处理完，便来到后面的优化器（Optimizer），它会产生多种执行计划,最终数据库会选择最优化的方案去执行,尽快返会结果。
(3)确定最优执行计划后，SQL语句此时便可以交由存储引擎（Engine）处理，存储引擎将会到后端的存储设备中取得相应的数据，并原路返回给程序。
并发控制和锁
当数据库中有多个操作需要修改同一数据时，不可避免的会产生数据的脏读。这时就需要数据库具有良好的并发控制能力，这一切在MySQL中都是由服务器和存储引擎来实现的。
解决并发问题最有效的方案是引入了锁的机制，锁在功能上分为共享锁(shared lock)和排它锁(exclusive lock)即通常说的读锁和写锁。当一个select语句在执行时可以施加读锁，这样就可以允许其它的select操作进行，因为在这个过程中数据信息是不会被改变的这样就能够提高数据库的运行效率。当需要对数据更新时，就需要施加写锁了，不在允许其它的操作进行，以免产生数据的脏读和幻读。锁同样有粒度大小，有表级锁(table lock)和行级锁(row lock)，分别在数据操作的过程中完成行的锁定和表的锁定。这些根据不同的存储引擎所具有的特性也是不一样的。
MySQL大多数事务型的存储引擎都不只是简单的行级锁，基于性能的考虑，他们一般在行级锁基础上实现了多版本并发控制(MVCC)。这一方案也被Oracle等主流的关系数据库采用。它是通过保存数据中某个时间点的快照来实现的，这样就保证了每个事务看到的数据都是一致的。详细的实现原理可以参考《高性能MySQL》第三版。
存储引擎
InnoDB引擎：
- 将数据存储在表空间中，表空间由一系列的数据文件组成，由InnoDB管理；
- 支持每个表的数据和索引存放在单独文件中(innodb_file_per_table)；
- 支持事务，采用MVCC来控制并发，并实现标准的4个事务隔离级别，支持外键；
- 索引基于聚簇索引建立，对于主键查询有较高性能；
- 数据文件的平台无关性，支持数据在不同的架构平台移植；
- 能够通过一些工具支持真正的热备。如XtraBackup等；
- 内部进行自身优化如采取可预测性预读，能够自动在内存中创建hash索引等。
MyISAM引擎：
- MySQL5.1中默认，不支持事务和行级锁；
- 提供大量特性如全文索引、空间函数、压缩、延迟更新等；
- 数据库故障后，安全恢复性差；
- 对于只读数据可以忍受故障恢复，MyISAM依然非常适用；
- 日志服务器的场景也比较适用，只需插入和数据读取操作；
- 不支持单表一个文件，会将所有的数据和索引内容分别存在两个文件中；
- MyISAM对整张表加锁而不是对行，所以不适用写操作比较多的场景；
- 支持索引缓存不支持数据缓存。
Archive引擎：
- 只支持insert和select操作；
- 缓存所有的写数据并进行压缩存储，支持行级锁但不支持事务；
- 适合高速插入和数据压缩，减少IO操作，适用于日志记录和归档服务器。
Blackhole引擎：
- 没有实现任何存储机制，会将插入的数据进行丢弃，但会存储二进制日志；
- 会在一些特殊需要的复制架构的环境中使用。
CSV引擎：
- 可以打开CSV文件存储的数据，可以将存储的数据导出，并利用excel打开；
- 可以作为一种数据交换的机制，同样经常使用。
Memory引擎：
- 将数据在内存中缓存，不消耗IO；
- 存储数据速度较快但不会被保留，一般作为临时表的存储被使用。
Federated引擎：
- 能够访问远程服务器上的数据的存储引擎。能够建立一个连接连到远程服务器。
Mrg_MyISAM引擎：
- 将多个MYISAM表合并为一个。本身并不存储数据，数据存在MyISAM表中间。
NDB集群引擎：
- MySQL Cluster专用。
存储引擎选取因素
1.是否有事务需求
如果需要事务支持最好选择InnoDB或者XtraDB，如果主要是select和insert操作MyISAM比较合适，一般使用日志型的应用。
2.备份操作需求
如果能够关闭服务器进行备份，那么该因素可以忽略，如果需要在线进行热备份，则InnoDB引擎是一个不错的选择。
3.故障恢复需求
在对恢复要求比较好的场景中推荐使用InnoDB，因为MyISAM数据损坏概率比较大而且恢复速度比较慢。
4.性能上的需求
有些业务需求只有某些特定的存储引擎才能够满足，如地理空间索引也只有MyISAM引擎支持。所以在应用架构需求环境中也需要管理员折衷考虑，当然从各方面比较而言，InnoDB引擎还是默认应该被推荐使用的。
Mysql事务
1.简单的说事务就是一组原子性的SQL语句。可以将这组语句理解成一个工作单元，要么全部执行要么都不执行。在MySQL中可以使用如下命令操作事务：
start transaction;
select ...
update ...
insert ...
commit;
注意：默认MySQL中自动提交是开启的：
2.事务具有ACID的特性：
- 原子性(atomicity):事务中的所有操作要么全部提交成功，要么全部失败回滚。
- 一致性(consistency):数据库总是从一个一致性状态转换到另一个一致性状态。
- 隔离性(isolation):一个事务所做的修改在提交之前对其它事务是不可见的。
- 持久性(durability):一旦事务提交，其所做的修改便会永久保存在数据库中。
3.事务的隔离级别：在SQL标准中定义了四种隔离级别：
- READ UNCOMMITTED(读未提交)：事务中的修改即使未提交也是对其它事务可见
- READ COMMITTED(读提交)：事务提交后所做的修改才会被另一个事务看见，可能产生一个事务中两次查询的结果不同。
- REPEATABLE READ(可重读)：只有当前事务提交才能看见另一个事务的修改结果。解决了一个事务中两次查询的结果不同的问题。
- SERIALIZABLE(串行化)：只有一个事务提交之后才会执行另一个事务。
4.死锁：两个或多个事务在同一资源上相互占用并请求锁定对方占用的资源，从而导致恶性循环的现象。MySQL的部分存储引擎能够检测到死锁的循环依赖并产生相应的错误。InnoDB引擎解决死锁的方案是将持有最少排它锁的事务进行回滚。
本文来自投稿，不代表本人立场，如若转载，请注明出处：http://www.souzhinan.com/kj/221338.html