MySQL插件式存储引擎架构
MySQL两种常用存储引擎分析
MyISAM
MySQL5.5之前版本默认存储引擎
其中系统表、临时表（在排序、分组等操作中，当数量超过一定的大小之后，由查询优化器建立的临时表）使用MyISAM
特性：表级锁、并发性不行、可以表损坏修复、支持全文索引、支持数据压缩
限制：版本<MySQL5.0时默认表大小为4G，版本>MySQL5.0是默认表大小>256TB
适用场景：
非事务型应用、只读类应用、空间类应用
Innodb
MySQL5.5之后版本默认存储引擎
Innodb使用表空间进行 数据存储
比较：
系统表空间无法简单的收缩文件大小
系统表空间会产生IO瓶颈
独立表空间可以通过oprimize table命令收缩系统文件
独立表空间可以同时向多个文件刷新数据
建议：独立表空间（5.6后系统默认）
Innodb特性：是一种事务性存储引擎、完全支持事务的ACID特性、使用Redo Log存储已提交事务和Undo Log存储为提交事务
Innodb支持行级锁
行级锁可以最大程度的支持并发
行级锁是由存储引擎层实现的
补充：什么是锁
锁对主要作用是管理共享资源的并发访问
锁用于实现事务的隔离性（Redo Log和Undo Log实现了事务的原子性、一直性、持久性）
锁的类型
共享锁（也称读锁）
独占锁（也称写锁）
锁的粒度
表级锁
行级锁
阻塞和死锁
什么是阻塞
阻塞很正常，资源被排他锁阻塞
死锁是两个线程相互占用资源
mysql系统会自动处理阻塞和死锁
Innodb适合于大多数OLTP应用
数据库结构优化的目的
- 减少数据冗余
- 尽量避免数据维护中出现更新，插入和删除异常
插入异常：如果表中的某个实体随着另一个实体而存在。
更新异常：如果更改表中的某个实体的单独属性时，需要对多行进行更新。
删除异常：如果删除表中的某一实例则会导致其他实例的消失。
- 节约数据存储空间
数据库结构设计的步骤
需求分析：全面了解产品设计的存储需求
存储需求、数据处理需求、数据的安全性和完整性
逻辑设计：设计数据的逻辑存储结构
数据实体之间的逻辑关系、j解决数据冗余和数据维护异常
物理设计：根据所使用的数据库特点进行表结构设计
维护优化：根据实际情况对索引、存储结构等进行优化
数据库设计范式
反范式化设计
在开发中会常见，反范式化就是未了性能和读取效率的考虑而适当的对数据库设计范式的要求进行违法，而允许存在少量的数据冗余，换句话来说反范式就是使用空间来换取时间。
范式化优点
可以尽量的减少数据冗余
范式化的更新操作比反范式化更快
范式化的表通常比反范式化更小
范式化缺点
对于查询需要对多个表进行关联
使难进行索引优化
反范式化优点
可以减少表的关联
可以更好的进行索引优化
反范式化缺点
存在数据冗余及数据维护异常
对数据的修改需要更多的成本
物理设计
数据库、表及字段命名规范
可读性原则、表意性原则。
存储引擎
为表中的字段选择合适的数据类型
当一个列可以选择多个数据类型时，应该优先考虑数字类型，其次是日期或二进制类型，最后是字符类型。对于相同级别数据类型，应该优先选择占用空间小的数据类型。
1、数字类型在排序等操作中比字符快
2、数据小使用的数据页也小
如何选择整数类型
如何选择实数类型
DECIMAL(18,9) 需要9个字节来存储
如果是财务的数据就需要DECIMAL类型，因为他们相关不会偏移，不会，1+1=2.0000000000001
如何选择VARCHER和CHAR类型
使用建议：1、使用最小的符合需求的长度
2、varchar(5)和varchar(200)存储‘MySQL’字符串性能不同
3、varchar经常改变大小会容易页分裂
如何存储日期类型
主要事项：
1、
2、使用Int存储日期时间不如使用timestample类型
如何为Innodb 选择主键
主键应该尽可能的小
主键应该是顺序增长的
Innodb的主键和业务主键可以不同