MySQL最重要的特性是它的存储引擎架构，这种架构的设计将查询处理及其他系统任务和数据的存储/提取相分离。这种处理和存储分离的设计可以在使用时根据性能、特性以及其他需求来选择数据存储的方式。
逻辑架构
P2架构图
服务器通过API与存储引擎通信。这些接口屏蔽了不同存储引擎间的差异，使得这些差异对上层的查询过程透明。但存储引擎不会解析SQL，不同存储引擎间也不会进行通信，只是简单响应上层服务器的请求。
一旦客户端连接成功，服务器会验证客户端是否有执行某个特定查询的权限。
MySQL会解析查询并创建内部数据结构（解析树），然后进行优化，包括重写查询、决定表的读取顺序，以及选择合适的索引。
优化器并不关心表使用什么存储引擎，但存储引擎对于优化查询是有影响的。
并发控制
提高共享资源并发性的方式是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有资源。更理想的方式是只对会修改的数据片进行锁定。
锁策略，就是在锁的开销和数据安全性之间寻求平衡，这种平衡会影响到性能。MySQL存储引擎可以实现自己的锁策略和锁粒度。
表锁是最基本的锁策略，并且是开销最小的锁。
行级锁只是在存储引擎层实现，服务器层没有实现，完全不了解存储引擎中锁实现。
事务
start transaction开启事务，commit提交。
多个事务以不同顺序锁定资源，可能发生死锁；多个事务同时锁定同一资源，也会发送死锁。
InnoDB处理死锁，将持有最少行级排它锁的事务回滚。
死锁产生的双重原因：有些事因为真正的数据冲突，有些事由于存储引擎实现方式导致。
MySQL默认采用自动提交模式，如果不是显式开始一个事务，每个查询都被当作一个事务执行提交操作，autocommit设置。
DDL语句执行之前会强制执行commit提交当前的活动事务。
存储引擎
MySQL将每个数据库（schema）保存为数据目录下的一个子目录。创建表时，会在子目录下创建一个和表同名的.frm文件保存表的定义。
不同存储引擎保存数据和索引的方式是不同的，但表的定义是在MySQL服务层统一处理的。
InnoDB和MyISAM
InnoDB被设计用来处理大量短期事务，重要特性自动崩溃恢复特性。
将每个表的数据和索引放在单独文件中。
采用MVCC支持高并发，默认级别为RR，通过间隙锁防止幻读。
InnoDB是基于聚簇索引简历，主键列很大，其他索引都会很大。
InnoDB存储格式是平台独立的，通过一些机制支持真正的热备份。
内部做了很多优化，从磁盘读取数据采用可预测性的读，自动在内存中创建hash索引加快读操作，能够加速插入操作的插入缓冲区。
MyISAM不支持事务和和行级锁，重大的缺陷是崩溃后无法安全回复，支持全文索引，这是基于分词创建的索引，可支持复杂的查询。
如果表在创建导入数据后，不会再进行修改，适合采用MyISAM亚索表。
如果不需要事务，主要是select和insert，MyISAM是不错的选择。若需要在线热备份（在数据库运行过程中，保存执行过的sql语句），InnoDB是基本要求。
转换存储引擎
alter table mytable engine=InnoDB;
需要执行很长时间，会按行将数据从原表复制到一个新表中，复制期间可能会消耗系统所有的I/O能力，同时在原表上加上读锁。
可以使用mysqldump工具将数据导出到文件，修改文件中create table语句的存储引擎选项，注意要修改表名。mysqldump默认自动在create table前加上drop table语句，可能导致数据丢失。
创建查询
insert into innodb_table select * from myisam_table;
