下图展示MySQL服务器逻辑架构图
1.1 连接管理与安全性
每个客户端连接服务器都会拥有一个线程，该线程只能在某个CPU核心或者CPU中运行。服务器也会缓存该线程，所以不用为每个新建的连接创建或者销毁线程。
1.2 优化与执行
MySQL内部有对查询进行自动优化，我们也可以通过关键字提示(hint)优化器来影响它的决策过程，更可以请求优化器解释优化过程的各个因素。另外执行select查询语句之前，MySQL都会先检查查询缓存，如果能找到对应查询就不必进行接下来的解析查询和优化等操作。
2.1 读写锁
在处理并发读和写的时候，可以实现一两种类型锁组成的锁系统来解决问题。这两种类型的锁通常被称为共享锁和排他锁，也叫读锁和写锁。读锁是共享的，而写锁会阻塞其他的读锁和写锁。
2.2 锁粒度
一种提高共享资源并发性的方式就是让锁定对象更有选择性，即只锁需要修改的部分数据。
所谓的所策略就是在锁的开销和数据的安全性之间寻找平衡。因为获得锁，检查锁是否已经解除，释放锁等操作都是会消耗资源的。一般企业都是表上施加行级锁。下面介绍两种锁策略：
表锁
MySQL中最基本的锁策略，并且是开销最小的策略。它会锁定整张表。
行级锁
行级锁可以最大程度的支持并发操作(但也是锁开销最大的)。行级锁只在存储引擎层实现，而MySQL服务器层并未实现。
3.1 隔离级别
READ UNCOMMITTED(未提交读)
事务中的修改在还没有提交的情况下对其他事务也是可见的，事务可以读取未提交的数据，这也被称为脏读。在性能上这个级别反而并不会比其他级别好很多，还缺乏其他级别的很多好处。
READ COMMITTED(提交读)
大多数数据库的默认隔离级别都是提交读(MySQL不是)。提交读只能看到已经提交的事务所作的修改。也就是，一个事务从开始到提交之前，所做的任何修改对其他事务都是不可见的。READ COMMITTED(提交读)也叫不可重复读，因为两次执行同样的查询，可能得到的结果却是不一样的。
REPEATED READ(可重复读)
可重复读解决的脏读的问题，该级别保证了在同一个事务中多次多次读取同样记录的结果是一致的。但是理论上，它还是无法决绝另外一个幻读的问题。幻读就是在某个事务读取某个范围的记录时，另一个事务又在该范围内插入了新的记录，在之前的事务再次读取该范围的记录时，就会产生幻行。InnoDB和XtraDB存储引擎通过多版本并发控制(MVCC)解决了幻读问题。
可重复读是MySQL的默认事务隔离级别。
SERIALIZABLE(可串行化)
最高的隔离级别。它会在读取每一行数据都给其加上锁，这有可能会造成大量的超时和锁争用问题。
3.2 死锁
概念:
死锁是指两个或多个事务在同一资源上互相占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。
InnoDB目前处理死锁的方法是:将持有最少行级排它锁的事务进行回滚。
3.3 事务日志
暂略。。。。。。
3.4 MySQL中的事务
MySQL中提供两种事务性的存储引擎:InnoDB和NDB Cluster。另外还有一些第三方的存储引擎。
自动提交(AUTOCOMMIT)
MySQL默认采用自动提交模式。也就是说，如果不是显式的开始一个事务，则每个查询都被当作一个事务执行提交操作。可以通过设置来启动或者停止自动提交模式。set autocommit = 1;1或ON表示启用，0或OFF表示禁用，直到显式的执行commit提交或者rollback回滚。
MySQL改变当前会话隔离级别：
set session transaction(如果不加session则是整个隔离级别都改变) isolation level read committed
在事务中混合使用存储引擎
因为MySQL服务器层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，适应多种存储引擎是不可靠的。
如果在事务中混和使用事务型和非事务型的表(如:InnoDB和MyISAM表)，在正常提交的情况下不会有什么问题。
在非事务型的表上执行事务相关操作的时候，MySQL通常不会发生提醒，也不会报错。有的时候只有回滚的时候才会发生警告:"某些非事务型的表上的变更不能被回滚"。然而大部分情况下，对非事务型表的操作都不会有提示。
隐式和显式锁定
原文：https://www.cnblogs.com/huqingan/p/11905845.html