【实现】mysql逻辑架构

• 存储引擎负责Mysql中数据的存储和提取。服务器听过API与存储引擎进行通信，这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。但存储引擎不回去解析SQL，不通存储引擎之间也不回相互通信，而只是简单地响应上层服务器的请求。
• 每个客户端链接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程。(线程池？)
• 认证+查询权限吗
• 优化器并不关心表使用的是什么存储引擎，但存储引擎对于优化查询是有影响的。（提供决策支持）
• 在实际的数据库系统中，每时每刻都在发生锁定，当某个用户在修改某一部分数据时，mysql会通过锁定防止其他用户读取同一数据。大多数时候，mysql锁的内部管理都是透明的。
• 加锁也需要消耗资源，锁的各种操作，包括获得锁，检查锁是否已经解除，释放锁等，都会等加系统的开销。如果系统花费大量的时间来管理锁，而不是存取数据，那么系统的性能可能会因此收到影响。所谓锁策略，就是在锁的开销和数据的安全性之间寻求平衡，这种平衡当然也会影响到性能。大多数商业数据库系统没有提供更多的选择，一般都是在表上施加行级锁，并以各种复杂的方式来实现，以便在锁比较多的情况下尽可能的提供更好的性能。
• 表锁：写锁阻塞其他用户对该表的所有读写操作，只有没有写锁时，其他读取的用户才能获得读锁，读锁之间是不想糊阻塞的。（读写者模式，也不全是）一个写锁请求可能会被插入到读锁队列的前面，反之读锁则不能插入到写锁前面。
• 尽管存储引擎可以管理自己的锁，mysql本身还是会使用各种有效的表锁来实现不同的目的。例如，服务器会为注入alter table之类的语句使用表锁，而忽略存储引擎的锁机制。
• 行级锁只在存储引擎层实现，而msql服务器层没有实现。
• InnoDB目前处理死锁的方法是，将持有最少行级拍他锁的事务进行回滚（这是相对比较简单的思索回滚算法）
• 事务日志采用的是追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，。事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘。目前大多数存储引擎都是这样实现的，我们通常称之为预写日志，修改数据需要写两次磁盘。
• mysql提供了两种事务型的存储引擎：InnoDB和NDBCluster。
• Mysql默认采用自动提交模式。也就是说，如果不是显式地开始一个事务，则每个查询都被当作一个事务执行提交操作。
• Mysql服务器层不管理事务，事务是由下层的存储引擎实现的。所以在同一个事务中，使用多种存储引擎是不可靠的。
• mysql的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，他们一般都同时实现了多版本并发控制。InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间。当然存储的并不是实际的时间值。而是系统版本号。每开始一个新的事务，系统版本号都会自动递增。事物开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。保存这两个额外系统版本号，使大多数读操作系统都可以不用加锁。MVCC只在REPEZTABLE READ和READ COMMITTED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容，因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁
• 复制是mysql成为互联网应用的数据库系统的关键特性(killer feature)