1 设计 - 存储引擎的选择
逐渐演变成: “选择MySQL 还是 MariaDB?”
1.1 结论
新版本的MySQL的话, 选择Innodb没错的.
依据基本功能选择.
MyISAM: 擅长处理快速的查询和插入. 典型的web程序的形态.
Innodb: 擅长大量并发, 处理大量的更新操作. 支持事务, 外键约束.
1.2 MyISAM
1.2.1 存储机制
数据和索引, 分开到不同的文件中进行存储
table.myi
table.myd
数据依据于插入顺序进行物理存储的:
由于插入时, 每次不进行排序, 直接插入到表的末尾, 速度比较快.
但是也带来了一个问题. 删除空洞的问题.
如果某些记录被删除了. 原本记录所占用存储空间, 插入是不会利用.
myiam表的这种机制, 导致需要手动的定期去修复空洞.
演示: 创建大点是数据表
自己复制自己的方式增加大量的重复数据
原始的数据
flush table 快速刷新内容到磁盘.
删除一半的数据
删除的结果
修复该表:使用repair tabletable-name
文件大小:
1.2.2 特殊功能
<=5.6全文索引. (很鸡肋, 不支持中文, 没人用)
数据myd文件支持压缩存储, 最小的使用磁盘空间. (不是很常用, 一旦压缩, 表不可编辑, 只能读取. 磁盘空间成本很低)
1.2.3 并发支持
相对差!
仅仅支持: table-level lock, 表级锁定
1.3 Innodb
1.3.1 存储机制
数据和索引是集中(聚簇, 聚集)存储的, 存储在.ibd的表空间文件中:
(PS: 表空间文件, 在新版本中, 默认是每张表一个表空间. 稍微早一点的版本, 所有的innodb一个表空间文件.
需要配置,innodb_file_per_table配置项, 每个表一个文件
设置为低版本
)
数据的存储顺序, 依据主键排序的
1.3.2 特殊功能
事务支持, 外键支持
事务, 典型数据的必备的特征, 用于保证数据的完整性. 通过ACID(原子性,一致性,隔离性,持久性)的支持实现.
外键约束: 典型的用于保证数据关系完整性机制. MySQL层面.
对于程序员来说, 无论数据库层面是否保证的数据关系的完整性, 在应用程序层面一定要保证
1.3.3 并发支持
相对好!
支持:table-level lock表级锁定 , row-level lock 行级锁定.
智能选择使用什么级别的锁定!
支持: MVCC机制, 多版本并发控制, 来提升锁定带来的效率问题. 几乎可以做大, 非锁定读操作!
1.4 show engines,查看支持的存储引擎
MySQL支持大量的存储引擎.
例如
1.5 memory, 缓存型存储引擎
数据和索引, 存储在内存中
仅仅存在 .frm结构文件!
我们也可以操作该表.
在 服务器重启后, 数据丢失!
不适合做持久化存储, 但适合做缓存系统.mysql内部的临时表也采用该存储引擎存储!
但是, memory表, 不支持 text,blob(二进制数据) 大块的数据!
1.6 archive, 存档型
高速存档型 类似myisam
常规操作:
仅支持添加和查询, 更高效.
不支持修改和删除.
适合做, 日志类系统!