【高并发高性能高可用之海量数据MySQL实战】-提纲目录-不断更新中...

1：引言

你是否遇到以下问题？

1：查询优化中不要select *，要用in，不能用or，为什么？
2：数据量大之后分库分表，那拆分规则是什么？怎么处理后续问题？
3：数据库挂了怎么处理？万能重启之法，然后听天由命？
4：先拆分还是先做集群，主从复制如何处理主库从库数据不一致？

你该如何解决的？

遇事不决量子力学？东一枪西一炮？

2：概述

        本人在开课吧学习的数据库相关的课程已告一段落。 

        从今天开始将基于最新的MySQL 8.0版本对MySQL从架构，存储引擎，事务管理，索引实现原理，各种锁机制原理全方位，多角度进行刨析。

        以解决实战生产问题为目的，对MySQL性能，优化，分库分表，故障处理等等进行讲解。
        既是对课程笔记的整理，也是自己对学习成果的复盘。

3：课程主体

【高并发高性能高可用之海量数据MySQL实战-1】-MySQL 8.0安装：操作系统：CentOS 7，MySQL：8.0。

【高并发高性能高可用之海量数据MySQL实战-2】-MySQL文件结构：MySQL是通过文件系统对数据和索引进行存储的。MySQL从物理结构上可以分为日志文件和数据索引文件。

【高并发高性能高可用之海量数据MySQL实战-3】-MySQL逻辑架构图：逻辑结构分为Server层与存储引擎层。

【高并发高性能高可用之海量数据MySQL实战-4】-InnoDB存储引擎之磁盘结构：InnoDB的主要的磁盘文件主要分为三大块：一是表空间，二是双写缓冲区，三是重做日志，数据字典表空间。

【高并发高性能高可用之海量数据MySQL实战-5】-InnoDB存储引擎之内存结构：内存结构：包括缓冲池（buffer pool)，修改缓存区(change buffer)，自适应hash，Log Buffer重做日志缓冲。

【高并发高性能高可用之海量数据MySQL实战-6】-MySQL自适应哈希索引：哈希(hash)是一种非常快的查找方法,在一般情况下这种查找的时间复杂度为O(1),即一般仅需要一次查找就能定位数据。InnoDB存储引擎会监控对表上各索引页的查询。如果观察到建立哈希索引可以带来速度提升,则建立哈希索引,称之为自适应哈希索引(Adaptive Hash Index,AHI) 。

【高并发高性能高可用之海量数据MySQL实战-7】-内存数据落盘：WAL要求数据的变更写入到磁盘前，首先必须将内存中的日志写入到磁盘；当一个事务提交时，所有产生的日志都必须刷新到磁盘上。

【高并发高性能高可用之海量数据MySQL实战-8】-InnoDB的事务隔离机制：事务是数据库最为重要的机制之一，凡是使用过数据库的人，都了解数据库的事务机制，也对ACID四个基本特性如数家珍。但是聊起事务或者ACID的底层实现原理，往往言之不详，不明所以。在MySQL中的事务是由存储引擎实现的，而且支持事务的存储引擎不多，我们主要讲解InnoDB存储引擎中的事务。

【高并发高性能高可用之海量数据MySQL实战-9】-事务并发控制解决方案LBCC与MVCC：两个事务针对同一数据都发生修改操作时，会存在丢失更新问题。什么是LBCC，什么是MVCC，该如何选择？

【高并发高性能高可用之海量数据MySQL实战-10】-InnoDB中MVCC的实现原理解读：MVCC是用于数据库提供并发访问控制的并发控制技术。MVCC最大的好处，读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。MVCC 在mysql 中的实现依赖的是 undo log 与 read view 。

【高并发高性能高可用之海量数据MySQL实战-11】-基于 MVCC 实现事务的隔离级别：mvcc 只支持 RC 和 RR 两种事务隔离级别。READ COMMITTED，读已提交，每次读取数据前都生成一个ReadView。REPEATABLE READ，可重复读，在事务开始后第一次读取数据时生成一个ReadView。

【高并发高性能高可用之海量数据MySQL实战-12】-MVCC下的读操作：在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。快照读：读取的是记录的可见版本 (有可能是历史版本)，不用加锁。当前读：读取的是记录的最新版本，并且当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。

【高并发高性能高可用之海量数据MySQL实战-13】-事务回滚和数据恢复：事务的隔离性由多版本控制机制和锁实现，而原子性，持久性和一致性主要是通过redo log、undo log和Force Log at Commit机制机制来完成的。redo log用于在崩溃时恢复数据，undo log用于对事务的影响进行撤销，也可以用于多版本控制。而Force Log at Commit机制保证事务提交后redo log日志都已经持久化。

【高并发高性能高可用之海量数据MySQL实战-14】-MySQL索引-二叉查找树-红黑树-B树-B+树：检索效率：可以提高数据检索的效率，降低数据库的IO成本，类似于书的目录。快速排序：通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗。被索引的列会自动进行排序，包括【单列索引】和【组合索引】，只是组合索引的排序要复杂一些。如果按照索引列的顺序进行排序，对应order by语句来说，效率就会提高很多。

【高并发高性能高可用之海量数据MySQL实战-15】-MySQL索引实现：主要是对MyISAM索引与InnoDB索引进行拆解。

【高并发高性能高可用之海量数据MySQL实战-16】-MySQL索引创建原则:哪些情况需要创建索引， 频繁出现在where 条件字段，order排序，group by分组字段；select 频繁查询的列，考虑是否需要创建联合索引（覆盖索引，不回表）； 多表join关联查询，on字段两边的字段都要创建索引。

【高并发高性能高可用之海量数据MySQL实战-17】-MySQL索引优化失效分析实战:对10种不同使用场景中索引失效进行拆解分析。

【高并发高性能高可用之海量数据MySQL实战-18】-MySQL全局锁|表级锁|行锁：数据库为多用户共享的，当出现并发访问的时候，需要使用锁来控制资源的访问。根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。

【高并发高性能高可用之海量数据MySQL实战-19】-MySQL锁原理分析实战：按照锁的粒度来说，MySQL主要包含三种类型（级别）的锁定机制：全局锁：锁的是整个database。由MySQL的SQL layer层实现的表级锁：锁的是某个table。由MySQL的SQL layer层实现的。行级锁：锁的是某行数据，也可能锁定行之间的间隙。由某些存储引擎实现，比如InnoDB。按照锁的功能来说分为：共享锁和排他锁。

【高并发高性能高可用之海量数据MySQL实战-20】-MySQL行锁分析实战：在介绍完一些背景知识之后，接下来将选择几个有代表性的例子，来详细分析MySQL的加锁处理。当然，还是从最简单的例子说起。经常有朋友发给我一个SQL，然后问我，这个SQL加什么锁？就如同下面两条简单的SQL，他们加什么锁？

【高并发高性能高可用之海量数据MySQL实战-21】-一条复杂SQL的加锁实战分析：一条SQL语句会加什么锁？假定在Repeatable Read隔离级别下会走什么索引。在详细分析这条SQL的加锁情况前，还需要有一个知识储备，那就是一个SQL中的where条件如何拆分？  

【高并发高性能高可用之海量数据MySQL实战-22】-MySQL死锁原理与分析：深入理解MySQL如何加锁，有两个比较重要的作用：可以根据MySQL的加锁规则，写出不会发生死锁的SQL；可以根据MySQL的加锁规则，定位出线上产生死锁的原因。

【高并发高性能高可用之海量数据MySQL实战-23】-MySQL性能优化之慢查询日志：数据库查询快慢是影响项目性能的一大因素，对于数据库，我们除了要优化 SQL，更重要的是得先找到需要优化的SQL。MySQL数据库有一个“慢查询日志”功能，用来记录查询时间超过某个设定值的SQL语句，这将极大程度帮助我们快速定位到症结所在，以便对症下药。

【高并发高性能高可用之海量数据MySQL实战-24】-MySQL性能优化之查看执行计划：MySQL 提供了一个 EXPLAIN 命令, 它可以对 SELECT 语句的执行计划进行分析, 并输出 SELECT 执行的详细信息, 以供开发人员针对性优化.使用explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描，这都可以通过explain命令来查看。

【高并发高性能高可用之海量数据MySQL实战-25】-MySQL性能优化之Query Profiler分析语句：Query Profiler是MySQL自带的一种query诊断分析工具，通过它可以分析出一条SQL语句的硬件性能瓶颈在什么地方。通常我们是使用的explain,以及slow query log都无法做到精确分析，但是QueryProfiler却可以定位出一条SQL语句执行的各种资源消耗情况，比如CPU，IO等，以及该SQL执行所耗费的时间等。不过该工具只有在MySQL 5.0.37以及以上版本中才有实现。

【高并发高性能高可用之海量数据MySQL实战-26】-MySQL性能优化之索引及SQL语句优化：表记录很少不需创建索引 ， 一个表的索引个数不能过多，频繁更新的字段不建议作为索引，区分度低的字段，不建议建索引，在InnoDB存储引擎中，主键索引建议使用自增的长整型，避免使用很长的字段，不建议用无序的值作为索引， 尽量创建组合索引，而不是单列索引。

【高并发高性能高可用之海量数据MySQL实战-27】-MySQL服务器层面优化：将数据保存在内存中，保证从内存读取数据。设置足够大的innodb_buffer_pool_size ，将数据读取到内存中。

4：寄语

        再紧张的裁员氛围，也不该影响你学习的心态。不要本末倒置，技术永远不会落后，只要你还在学习的道路上，没有后退。

5：参考

开课吧-在线职业教育