MySQL之相关基本概念简介

4eter

关于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的相关概念还有很多，这里只是简略的介绍下，望大家指正！