MySQL架构与历史
第一章 MySQL架构与历史
之前没有学过MySQL，借此机会边看课程边翻书，加油！
1.1 MySQL逻辑架构
- 最上层
- 连接处理、授权处理、安全等
- 第二层
- 存储过程、触发器、视图等
- 第三层
- 存储引擎
1.2 并发控制
1.2.1 读写锁
- 共享锁（读锁）：多个用户在同一时刻可以读取同一资源，而互不干扰
- 排它锁（写锁）：一个写锁会阻塞其他的写锁和读锁
1.2.2 锁策略
- 表锁
- 最基本、开销最小的锁策略
- 写锁请求优先级更高
- 行级锁
- 开销大
- 支持并发处理
1.3 事务
如果数据库引擎能够成功地对数据库应用该组查询的全部语句，就执行该组查询；如果其中有任何一条语句因为某些原因无法执行，那么所有语句都不会执行。
1.3.1 ACID
- atomicity（原子性）：不能只执行其中的一部分操作
- consistency（一致性）：数据库总是从一个一致性的状态转换到另一个一致性的状态
- isolation（隔离性）：一个事务所做的修改在最终提交以前，对其他事务是不可见的。
- durability（持久性）：一旦事务提交，则其所做的修改就会永久保存到数据库中。
1.3.2 隔离级别
1.3.3 死锁
两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。当多个事务视图以不同的顺序锁定资源时，就可能会产生死锁。
- InnDB处理死锁的方法
- 将持有最少行级排它锁的事务进行回滚
1.3.4 事务日志
存储引擎在修改表的数据时，只需要修改其内存拷贝，再将修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。
1.4 多版本并发控制
1.5 MySQL的存储引擎
1.5.1 InnoDB存储引擎（*）
设计用来处理大量的短期事务，这类事务大多数情况是正常提交的，很少会回滚。
1.5.2 MyISAM存储引擎
在MySQL5.1及之前的版本，这是默认的存储引擎。提供了大量的特性，包括全文索引、压缩、空间函数（GIS）等，但不支持事务和行级锁，且崩溃后无法安全恢复
- 特性：
- 加锁与并发
- 修复
- 索引特性
- 延迟更新索引建
1.5.3 选择合适的引擎
我们知道MySQL有内建的其他存储引擎，还有第三方存储引擎；大多数情况下，InnoDB都是正确的选择，所以在MySQL5.5版本时将InnoDB作为默认的存储引擎了。
除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，否则都应该优先选择InnoDB引擎。
- 日志型应用：MyISAM或者Archive
- 开销低
- 插入速度快
- 只读或者大部分情况下只读的表
- 不介意崩溃恢复问题，选用MyISAM
- MyISAM引擎在一开始可能没有任何问题，应用压力上升可能会迅速恶化
- 订单处理：InnoDB
- 支持事务是必要选项
- 电子公告牌和主体讨论论坛：
- CD-ROM应用：可以考虑MyISAM表或者压缩表
- 大数据量：Infobright
- 数据量在10TB以上的级别
1.5.4 转换表的引擎
书中介绍了三种方法，及各自的优缺点。
- ALTER TABLE
- 导入与导出
- 创建与查询（CREATE和SELECT）
1.6 MySQL时间线（Timeline）
由于时间问题暂时未读
1.7 MySQL的开发模式
目前已基本稳定，在Oracle定期发布的新里程碑开发版本中，会包含即将在下一个GA（Generally Available）版本发布的新特性。MySQL遵循GPL开源协议，全部的源代码（除了一些商业版本的插件）都会开放给社区。
总结
InnoDB对大多数用户是最佳选择。
本周阅读时间仓促，相信在下面时间的学习中自己可以多应用、多理解。