MySQL 存储引擎
实际执行对数据库数据的存取。目前 MySQL 默认使用 InnoDB 引擎。相比于过去使用 MyISAM 引擎,有以下几个优势:
索引:数据文件本身是主索引。
外键:支持外键。
事务:添加本地日志,支持安全恢复;支持行级锁,提高并发度。
并发:支持多版本并发控制,提升性能。
索引
存储结构
MySQL 数据库使用以下两种数据结构存储和查找数据:
B+ 树:(默认)适用于连续查询多条数据。
哈希表:适用于查询单条数据。
索引类型
索引名称|索引类型|字段类型|备注 -|-|- PRIMARY KEY|主索引|主键|字段值不能重复,也不能为空。 INDEX|普通索引|自定义字段|无,效率低。 UNIQUE|唯一索引|自定义字段|字段值不能重复,效率高。 FULLTEXT|文本索引|自定义字段|无,用于文本检索。
主索引
在 InnoDB 存储引擎中数据文件本身就是主索引(聚簇索引):数据以 B+ 树形式存储,根据主键值进行排序。
我们可以为其他字段建立辅助索引(非聚簇索引),以提高对字段的查询速度,但同时会降低表的更新速度。在辅助索引中记录主键值而不是字段地址:根据辅助索引查找后,仍需要根据主键值在主索引中查询数据。
组合索引
索引内可以包含多个字段,N 个字段的组合索引实际建立了 N 个索引。
对 a/b/c 三个字段建立的组合索引,实际会先在 a 索引中查找,再到 a/b 索引中查找,最后在 a/b/c 索引中查找。
视图
视图是一个虚拟表,不实际存储数据。其内容会通过查询其他表得到,在引用视图时动态生成。
权限管理:表的权限管理不能限制到具体的行和列,但通过视图则可以限制用户能得到的结果集。
数据独立:表的结构发生变化,不会对用户使用视图查询到的数据产生影响。
外键
从表通过外键关联到主表的主键,建立数据表之间的关系。
优点:保障数据的一致性和完整性。
缺点:增加数据之间的耦合度,难以集群。因此不推荐使用外键。
删除策略
对主表的数据进行 UPDATE/DELETE 操作时,将会会影响到关联的从表。
日志
当数据库数据发生更改时,用日志记录数据库操作。当发生错误或者冲突时,可以进行回滚。保证数据的一致性。
bin log 归档日志
最开始 MySQL 并没与 InnoDB 引擎,其他存储引擎只有通用的 bin 日志用来归档(位于 server 层)。
InnoDB 引擎完成主存数据更新后向执行器提交,由 bin 日志记录操作。如果主存数据已更新,且 bin 日志没有被写入时数据库崩溃,后续进行机器备份的时候就会丢失原有数据。这导致数据没有安全恢复的能力:一旦数据库发生异常重启,之前提交的记录都会丢失。
redolog 重做日志
MySQL 引入 InnoDB 引擎后,自带了 redo 日志。用于数据库发生异常重启时系统记录的恢复。
InnoDB 引擎完成主存数据更新但还未提交时,由 redo 日志记录操作并进入 prepare 状态。
InnoDB 引擎向执行器提交时,由 bin 日志记录操作。
提交完成后执行器通知 InnoDB 引擎,redo 日志进入 commit 状态。
如果 bin 日志没有被写入时数据库崩溃,后续进行机器备份的时候就会按照 redo 日志恢复数据。
如果 bin 日志已经写完但 redo 日志还处于 prepare 状态时数据库崩溃。MySQL 会判断 redo 日志是否完整,如果完整就立即提交。否则再判断 bin 日志是否完整,如果完整就提交 redo 日志,不完整就回滚事务。这样就解决了数据一致性的问题。
版权声明: 本文为 InfoQ 作者【武师叔】的原创文章。
原文链接:【http://xie.infoq.cn/article/05d910ee8baf10952d48f92d9】。文章转载请联系作者。
评论