mysql数据库结构分析

1. mysql逻辑框架
   客户端——>查询缓存——>解析器——>优化器——>存储引擎

2. 并发控制(锁的应用)

   • 读写锁( 读锁【read lock】共享,写锁【weite lock】排他)
   • mysql根据不同的搜索引擎，采用了大量的锁粒度和锁策略
   • 表锁(【table lock】是开销最小的策略,会锁定整张表,在进行【读，写，改】前，会获取写锁，阻塞其他用户对表的读写，只要没有写锁时，其他用户才能获得读锁)
   • 行锁(【row lock】)只在存储的时候实现
   • 死锁 两个或多个事务占用同一资源时,并请求占用对方资源时，造成的恶性循环，InnerDB检测到死锁状态会并立即返回一个错误，其他条件下，只能对占用排他锁少的事务进行回滚
   • 间隙锁【next-key locking】
     1. 触发条件
        必须在InnerDB可重用锁的级别下
        检索的条件必须有索引
     2. 间隙锁的锁和组成【Gap lock】+【Record lock】
     3. 锁机制:对在和不在范围查询内的索引加锁,在下次查询非范围内的数据时,不会出现幻读

3. 事务(ACID【原子性，一致性，持久性，隔离性】)
   - 原子性:要么全部执行，要么全部不执行
   - 隔离性:一个事务不会受到另一个事务的影响
   - 持久性:一个事务执行成功后对数据库是永久有效的
   - 一致性:事务提交失败后后事务中对数据库所做的修改不会生效

4. 事务的隔离级别

   • 未提交读READ UNCOMM!TTED【脏读】:在事务没有提交时，对其他的事务是可见的，事务可以读取为提交的数据
   • 提交读 READ COMMITTED:一个事务从开始到提交所做的一切操作不可被其他事务看见【不可重复读】——>其两次查询的结果可能不一致
   • 可重复读 REPEATABLE READ 可重复读解决了脏读的问题，该级别能保证在一个事务内,对同一个数据的读取是相同的，但可重复读有会产生新的问题幻读【 Phantom Read】:某个事务在读取某个范围内的数据时，另一个事务对范围内的数据进行插入，当之前的事务再对范围内的数据进行查询时会产生 幻行【PHantom Read】
   • 可串行化【SERIALZBLE】 最高的事务隔离级别，强制事务串执行，解决了幻读的问题，简单来说可串行化，在每次查询时会加上行级锁，大大影响性能，【不推荐使用】

5. mysql中的存储引擎，及其使用的场景

   • InnerDB mysql的默认引擎,也是最重要，最广泛的使用引擎
     • 应用场景：被设计处理短期的事务【short-lived】短期事务能被正常提交，很少会被回滚，InnerDB的性能和崩溃自动修复的特性，使其在非事务上也能被正常使用
     • 隔离级别的策略 采用可重复读，解决幻读的方法 间隙锁【next-key locking】(详情请往上翻)
   • MyISAM
     • 应用场景 在mysql5.1版本前的默认存储引擎
     • 缺点 不支持事务和行级锁，崩溃后无法安全恢复
     • 特性 MyISAM对于表数据是针对表而不是数据行 关于共享锁和排他锁和InnerDB无区别
   • Archive
     • 缺点 只支持select 和insert ，在mysql5.1前不支持事务
     • 应用场景每次的select都会扫描全表，表示着Archive只适合做数据分析
     • 适应性:Archive在面对批量插入的时候没有采用事务，而是针对高速插入和压缩做了简单的引擎优化
   • BlackHole
     特性
     没有任何的存储机制，他会丢弃所有的插入数据，不做保存，但是服务器会记录在Blackhole表中，当前引擎只能当做日志文件使用
     ****************以下略过Mysql内置引擎
   • 第三方存储引擎
     • OlTP【联机事务处理】
       • XtraDB: 可以看作是InnoDB存储引擎的增强版本，它在InnoDB上进行了大量的修改和patched，它完全兼容InnoDB，且提供了很多InnoDB不具备的有用的功能。
       • TuKoDB 在innerDB的基础上做出了改良 ，InnerDB使用B+结构， 但是TukoDB使用的是Featal+树
       • 简析分形树【featal+】
         • 特点存入结构中要么全空要么全满
         • 在插入数据时顺序插入因此获得了很好的写入性能
         • 是呈指数增长的结构，数据会默认插入最小的数组，空间不够的情况下会重新选择
     • 面向列的存储引擎(以上存储引擎都是面向行的)
       • 面向列的好处
         在面对大数据的情况下,面对列的数据效率更高
       • infobringht
         当前的引擎不支持索引数据，但是引擎的的负重性能在数10tb下也能有良好的运行速度
         关于infobringht数据的优缺点分析
     • 社区类引擎
       • ARIA 解决了MyISAM面对数据崩情况

6. 如何选择合适的数据引擎

   1. 在默认的条件下，我们仍然使用InnerDB数据引擎，除非用到完全不需要InnerDB引擎的时候才去考虑不同的引擎
   2. 尽量避免混合引擎的使用 可能会导致潜在的bug
   3. 如果不可避免的要使用多个不同的引擎，那么需要考虑到不同引擎对待事务的情况，优先考虑InnerDB 和XtraDB【innerDB强化器】，在事务的处理中处于优先地位
   4. 备份处理优先考虑InnerDB
   5. 崩溃恢复上InnerD比MyIsAm好太多
   6. 日志:(对数据的插入有较高的要求)MyISAM或者Archive存储引擎对这类应用比较合适， 面对日志分析情况下，采用主从备份的形式比较好（在主机中主要作为插入，从机做查询）
   7. 只读或者大部分情况只有读取时. 选用MyIsAm但是崩溃的风险仍然不容忽视
   8. 订单处理:innerDB比较合适
   9. 较高的请求数据中，往往只会设计几张表来存储热点信息，这种搞读写压力的情况下，往往只能靠锁来解决问题
   10. 海量数据，在多达几十tb的数据量下，无论是什么数据引擎都显得的乏力，解决办法只能是在mysql的下建立Infobringht数据仓库【对于不同类型的数据进行选择，清理之后的存储的地方】

7. 关于表引擎的转换

   1. ALTER TABLE XXXX ENGINE=InnoDB;
   2. 将表转化后，再次转化为原引擎，其中的外键会全部丢失

8. mysql 5.1 版本中新推出InnonDB plugIn引擎

9. 总结:mysql是一种分层的架构 ,其上层是采用上层采用服务器和查询引擎，下层采用数据存储引擎