MySQL之相关基本概念简介
关于MySQL
MySQL是一个多用户、多线程、开源的关系数据库管理系统,基于C/S结构。由MySQL AB公司开发,该公司在2008年被sun收购,sun在2009年又被Oracle收购,所以现在MySQL是旗下的产品。它采用双授权政策,分为社区版(无授权费)和商业版两种。
MySQL并不是一款完美的数据库,但其因足够灵活,能够适应要求较高的环境受到广泛的欢迎。
关于MariaDB
鉴于Oracle的人品,引发了开源社区对Oracle是否还会支持MySQL社区版的担忧,因此社区采用分支的方式来规避这种风险,于是MariaDB就应运而生了,它有MySQL的创始人Michael Widenius主导开发,完全兼容MySQL,可以轻松实现MySQL向MariaDB的迁移。在现在看来它们几乎是无区别的(当然,名字除外),因此,我们以后说MySQL是同时指的它们二者。
而且,在RHEL 7 当中,内置默认的数据库将不再是MySQL,而是MariaDB。
关于MySQL的逻辑架构
关于MySQL的锁
锁是并发访问的一种资源处理机制,解决资源的争用问题。
MySQL的锁分为读锁和写锁:
读锁:共享锁,互不阻塞,即多个用户可以在同一时刻读取同一资源而互不干扰;
写锁:独占锁,排他阻塞,即只有锁定的用户可以读或者写,其他用户只能等待锁定用户的事务完成或解锁后,才能在施加锁;
锁粒度:即锁的级别,大致分为两种:表锁、行锁;
表锁(table lock):锁定整张表,开销最小; 行锁(row lock):锁定需要的行,并发最好;
所谓锁粒度,其实就是锁开销和数据安全之间寻求平衡的一种策略;粒度越小,开销就越大,但并发性就越好;反正,粒度越大,开销就越小,但并发性就越差;
关于事务
事务可以理解为一组原子性的sql查询,或者说是一个独立的工作单元。其内部的语句,要么全部执行成功,要么全部执行失败。
事务的特性:
原子性(atomicity):一个事务必须被视为一个不可分割的最小工作单元,整个事务的所有操作要么全部提交成功,要么全部失败回滚,对于一个事务来说,不可能只执行其中的一部分操作;
一致性(consistency):数据库总是从一个一致性状态转换到另一个一致性状态;
隔离性(isolation):一个事务所做的修改在其提交之前,对其他事务是不可见的。
持久性(durability):一旦事务提交,则其所做的修改就会永久保存到数据库中。
隔离的级别
每种存储引擎的隔离级别是不尽相同的,但大致有四种隔离级别:
1、READ UNCOMMITTED(读未提交):在此级别下,事务中的修改,即使未提交,对其他事务也都是可见的。这个级别会导致很多问题,性能也与其他级别相差无几,所以在实际应用中一般很少使用;
2、READ COMMITTED(读提交):只有提交的是可读的,这是大多数数据库系统的默认隔离级别,但MySQL不是。
3、REPEATABLE READ (可重读):MySQL的默认级别,它确保在同一事务中多次读取同样记录的结果是一致的。
4、SERIALIZABLE(可串行化):最高的隔离级别,它强制事务串行执行。实际中很少用到,只有在非常需要确保数据的一致性而且可以接受没有并发的情况下,才考虑采用该级别。
MVCC
MVCC:Multi-Version Concurrency Control,多版本并发控制。它可以看着是行锁的一个变种,在很多情况下避免了加锁操作,因此开销更小。
MVCC的实现,是通过保持数据的某个时间点的快照来实现的。也就是说,不管需要执行多长时间,这个事务看到的数据是一致的。也可以说,不同的事务在同一时刻,看到的数据可能是不一样的。
MySQL的存储引擎
MyISAM:MySQL的默认存储引擎,不支持事务、外键和行级锁。崩溃后无法安全恢复数据。它的适用在只读数据,较小的表,能够容忍崩溃后的修改操作和数据丢失的场景下。
InnoDB:支持事务、MVCC、热备、行级锁等,提供了良好的事务管理、并发控制和良好的数据安全性,但其读写效率一般,且占用的数据空间相对较大。
MEMORY:保存数据在内存中,可提供极快的访问,常用于保存中间数据,如周期性的聚合数据等,也用于实现临时表。
Archive:仅支持INSERT和SELECT,不支持事务和不能很好的支持索引,支持很好的压缩功能,适用于存储日志信息,或者按时间序列实现的数据采集类的应用。
CSV:将数据存储为csv格式,不支持索引;仅适用于数据交换场景;但是存储浮点数的话,会损失精度。
BLACKHOLE:没有存储机制,任何发往此引擎的数据都会丢弃;其会记录二进制日志,因此,常用于多级复制架构中作中转服务器。
MRG_MYISAM:是MYISAM的一个变种,能够将多个MyISAM表合并成一个虚表。
NDB:是MySQL CLUSTER中专用的存储引擎。
第三方的存储引擎:
XtraDB: 增强的InnoDB,由Percona提供;编译安装时,下载XtraDB的源码替换MySQL存储引擎中的InnoDB的源码,并重命名为InnoDB。
PBXT: MariaDB自带此存储引擎,支持事务、MVCC支持引擎级别的复制、外键约束,对SSD磁盘提供适当支持。
TokuDB: 使用Fractal Trees索引,适用存储大数据,拥有很压缩比;已经被引入MariaDB。
开源社区存储引擎:
Aria:前身为Maria,可理解为增强版的MyISAM(支持崩溃后安全恢复,支持数据缓存)。
Groona:全文索引引擎,Mroonga是基于Groona的二次开发版。
OQGraph: 由Open Query研发,支持图结构的存储引擎。
SphinxSE: 为Sphinx全文搜索服务器提供了SQL接口。
Spider: 能数据切分成不同分片,比较高效透明地实现了分片(shared),并支持在分片上支持并行查询。
这么多的存储引擎,该怎么选择呢?
实际上,存储引擎之间并没有好和差的区别,只看适不适合我们使用,具体的选择可以从如下几个方面入手:
1、是否需要事务;
2、崩溃后的恢复;
3、备份类型的支持;
4、存储引擎特有的特性;
MySQL的相关概念还有很多,这里只是简略的介绍下,望大家指正!
本文出自 “一沙一天堂” 博客,请务必保留此出处http://5083089.blog.51cto.com/5073089/1395026
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。