mysql 核心内容-上

1、SQL语句执行流程

MySQL大体上可分为Server层和存储引擎层两部分。

Server层：

连接器：TCP握手后服务器来验证登陆用户身份，A用户创建连接后，管理员对A用户权限修改了也不会影响到已经创建的链接权限，必须重新登陆。

查询缓存：查询后的结果存储位置，MySQL80版本以后已经取消，因为查询缓存失效太频繁，得不偿失。

分析器：根据语法规则，判断你输入的这个SQL语句是否满足MySQL语法。

优化器：多种执行策略可实现目标，系统自动选择最优进行执行。

执行器：判断是否有权限，将最终任务提交到存储引擎。

存储引擎层

负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 555版本开始成为了默认存储引擎(经常用的也是这个)。

SQL执行顺序

2、BinLog、RedoLog、UndoLog

BinLog

BinLog是记录所有数据库表结构变更（例如create、alter table）以及表数据修改(insert、update、delete)的二进制日志，主从数据库同步用到的都是BinLog文件。BinLog日志文件有三种模式。

STATEMENT 模式

内容：binlog 记录可能引起数据变更的 sql 语句

优势：该模式下，因为没有记录实际的数据，所以日志量很少 IO 都消耗很低，性能是最优的

劣势：但有些 *** 作并不是确定的，比如 uuid() 函数会随机产生唯一标识，当依赖 binlog 回放时，该 *** 作生成的数据与原数据必然是不同的，此时可能造成无法预料的后果。

ROW 模式

内容：在该模式下，binlog 会记录每次 *** 作的源数据与修改后的目标数据，StreamSets就要求该模式。

优势：可以绝对精准的还原，从而保证了数据的安全与可靠，并且复制和数据恢复过程可以是并发进行的

劣势：缺点在于 binlog 体积会非常大，同时，对于修改记录多、字段长度大的 *** 作来说，记录时性能消耗会很严重。阅读的时候也需要特殊指令来进行读取数据。

MIXED 模式

内容：是对上述STATEMENT 跟 ROW 两种模式的混合使用。

细节：对于绝大部分 *** 作，都是使用 STATEMENT 来进行 binlog 没有记录，只有以下 *** 作使用 ROW 来实现：表的存储引擎为 NDB，使用了uuid() 等不确定函数，使用了 insert delay 语句，使用了临时表

主从同步流程：

1、主节点必须启用二进制日志，记录任何修改了数据库数据的事件。

2、从节点开启一个线程（I/O Thread)把自己扮演成 mysql 的客户端，通过 mysql 协议，请求主节点的二进制日志文件中的事件 。

3、主节点启动一个线程（dump Thread），检查自己二进制日志中的事件，跟对方请求的位置对比，如果不带请求位置参数，则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。

4、从节点接收到主节点发送过来的数据把它放置到中继日志（Relay log）文件中。并记录该次请求到主节点的具体哪一个二进制日志文件内部的哪一个位置（主节点中的二进制文件会有多个）。

5、从节点启动另外一个线程（sql Thread ），把 Relay log 中的事件读取出来，并在本地再执行一次。

mysql默认的复制方式是异步的，并且复制的时候是有并行复制能力的。主库把日志发送给从库后不管了，这样会产生一个问题就是假设主库挂了，从库处理失败了，这时候从库升为主库后，日志就丢失了。由此产生两个概念。

全同步复制

主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响。

半同步复制

半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写 *** 作完成。

还可以延伸到由于主从配置不一样、主库大事务、从库压力过大、网络震荡等造成主备延迟，如何避免这个问题？主备切换的时候用可靠性优先原则还是可用性优先原则？如何判断主库Crash了？互为主备的情况下如何避免主备循环复制？被删库跑路了如何正确恢复？( o )… 感觉越来越扯到DBA的活儿上去了。

RedoLog

可以先通过下面demo理解：

饭点记账可以把账单写在账本上也可以写在粉板上。有人赊账或者还账的话，一般有两种做法：

1、直接把账本翻出来，把这次赊的账加上去或者扣除掉。

2、先在粉板上记下这次的账，等打烊以后再把账本翻出来核算。

生意忙时选后者，因为前者太麻烦了。得在密密麻麻的记录中找到这个人的赊账总额信息，找到之后再拿出算盘计算，最后再将结果写回到账本上。

同样在MySQL中如果每一次的更新 *** 作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本、查找成本都很高。而粉板和账本配合的整个过程就是MySQL用到的是Write-Ahead Logging 技术，它的关键点就是先写日志，再写磁盘。此时账本 = BinLog，粉板 = RedoLog。

1、 记录更新时，InnoDB引擎就会先把记录写到RedoLog（粉板）里面，并更新内存。同时，InnoDB引擎会在空闲时将这个 *** 作记录更新到磁盘里面。

2、 如果更新太多RedoLog处理不了的时候，需先将RedoLog部分数据写到磁盘，然后擦除RedoLog部分数据。RedoLog类似转盘。

RedoLog有write pos 跟checkpoint

write pos ：是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。

check point：是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

write pos和check point之间的是粉板上还空着的部分，可以用来记录新的 *** 作。如果write pos追上checkpoint，表示粉板满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint推进一下。

有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。 redolog两阶段提交：为了让binlog跟redolog两份日志之间的逻辑一致。提交流程大致如下：

1 prepare阶段 --> 2 写binlog --> 3 commit

当在2之前崩溃时，重启恢复后发现没有commit，回滚。备份恢复：没有binlog 。一致

当在3之前崩溃时，重启恢复发现虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。备份：有binlog 一致

binlog跟redolog区别：

redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。

redo log是物理日志，记录的是在某个数据页上做了什么修改；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如给ID=2这一行的c字段加1。

redo log是循环写的，空间固定会用完；binlog是可以追加写入的。追加写是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

UndoLog

UndoLog 一般是逻辑日志，主要分为两种：

insert undo log

代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃

update undo log

事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

3、MySQL中的索引

索引的常见模型有哈希表、有序数组和搜索树。

哈希表：一种以KV存储数据的结构，只适合等值查询，不适合范围查询。

有序数组：只适用于静态存储引擎，涉及到插入的时候比较麻烦。可以参考Java中的ArrayList。

搜索树：按照数据结构中的二叉树来存储数据，不过此时是N叉树(B+树)。广泛应用在存储引擎层中。

B+树比B树优势在于：

B+ 树非叶子节点存储的只是索引，可以存储的更多。B+树比B树更加矮胖，IO次数更少。

B+ 树叶子节点前后管理，更加方便范围查询。同时结果都在叶子节点，查询效率稳定。

B+树中更有利于对数据扫描，可以避免B树的回溯扫描。

索引的优点：

1、唯一索引可以保证每一行数据的唯一性

2、提高查询速度

3、加速表与表的连接

4、显著的减少查询中分组和排序的时间

5、通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。

索引的缺点：

1、创建跟维护都需要耗时

2、创建索引时，需要对表加锁，在锁表的同时，可能会影响到其他的数据 *** 作

3、 索引需要磁盘的空间进行存储，磁盘占用也很快。

4、当对表中的数据进行CRUD的时，也会触发索引的维护，而维护索引需要时间，可能会降低数据 *** 作性能

索引设计的原则不应该：

1、索引不是越多越好。索引太多，维护索引需要时间跟空间。

2、 频繁更新的数据，不宜建索引。

3、数据量小的表没必要建立索引。

应该：

1、重复率小的列建议生成索引。因为重复数据少，索引树查询更有效率，等价基数越大越好。

2、数据具有唯一性，建议生成唯一性索引。在数据库的层面，保证数据正确性

3、频繁group by、order by的列建议生成索引。可以大幅提高分组和排序效率

4、经常用于查询条件的字段建议生成索引。通过索引查询，速度更快

索引失效的场景

1、模糊搜索：左模糊或全模糊都会导致索引失效，比如'%a'和'%a%'。但是右模糊是可以利用索引的，比如'a%' 。

2、隐式类型转换：比如select from t where name = xxx , name是字符串类型，但是没有加引号，所以是由MySQL隐式转换的，所以会让索引失效 3、当语句中带有or的时候：比如select from t where name=‘sw’ or age=14

4、不符合联合索引的最左前缀匹配：(A,B,C)的联合索引，你只where了C或B或只有B,C

关于索引的知识点：

主键索引：主键索引的叶子节点存的是整行数据信息。在InnoDB里，主键索引也被称为聚簇索引（clustered index）。主键自增是无法保证完全自增的哦，遇到唯一键冲突、事务回滚等都可能导致不连续。

唯一索引：以唯一列生成的索引，该列不允许有重复值，但允许有空值(NULL)

普通索引跟唯一索引查询性能：InnoDB的数据是按数据页为单位来读写的，默认每页16KB，因此这两种索引查询数据性能差别微乎其微。

change buffer：普通索引用在更新过程的加速，更新的字段如果在缓存中，如果是普通索引则直接更新即可。如果是唯一索引需要将所有数据读入内存来确保不违背唯一性，所以尽量用普通索引。

非主键索引：非主键索引的叶子节点内容是主键的值。在InnoDB里，非主键索引也被称为二级索引（secondary index）

回表：先通过数据库索引扫描出数据所在的行，再通过行主键id取出索引中未提供的数据，即基于非主键索引的查询需要多扫描一棵索引树。

覆盖索引：如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为覆盖索引。

联合索引：相对单列索引，组合索引是用多个列组合构建的索引，一次性最多联合16个。

最左前缀原则：对多个字段同时建立的组合索引(有顺序，ABC，ACB是完全不同的两种联合索引) 以联合索引(a,b,c)为例，建立这样的索引相当于建立了索引a、ab、abc三个索引。另外组合索引实际还是一个索引，并非真的创建了多个索引，只是产生的效果等价于产生多个索引。

索引下推：MySQL 56引入了索引下推优化，可以在索引遍历过程中，对索引中包含的字段先做判断，过滤掉不符合条件的记录，减少回表字数。

索引维护：B+树为了维护索引有序性涉及到页分裂跟页合并。增删数据时需考虑页空间利用率。

自增主键：一般会建立与业务无关的自增主键，不会触发叶子节点分裂。

延迟关联：通过使用覆盖索引查询返回需要的主键，再根据主键关联原表获得需要的数据。

InnoDB存储: frm文件是一份定义文件，也就是定义数据库表是一张怎么样的表。ibd文件则是该表的索引，数据存储文件，既该表的所有索引树，所有行记录数据都存储在该文件中。

MyISAM存储： frm文件是一份定义文件，也就是定义数据库表是一张怎么样的表。 MYD文件是MyISAM存储引擎表的所有行数据的文件。 MYI文件存放的是MyISAM存储引擎表的索引相关数据的文件。MyISAM引擎下，表数据和表索引数据是分开存储的。

MyISAM查询：在MyISAM下，主键索引和辅助键索引都属于非聚簇索引。查询不管是走主键索引，还是非主键索引，在叶子结点得到的都是目的数据的地址，还需要通过该地址，才能在数据文件中找到目的数据。

PS：InnoDB支持聚簇索引，MyISAM不支持聚簇索引

4、SQL事务隔离级别

ACID的四个特性

原子性（Atomicity）：把多个 *** 作放到一个事务中，保证这些 *** 作要么都成功，要么都不成功

一致性（Consistency）：理解成一串对数据进行 *** 作的程序执行下来，不会对数据产生不好的影响，比如凭空产生，或消失

隔离性（Isolation，又称独立性）：隔离性的意思就是多个事务之间互相不干扰，即使是并发事务的情况下，他们只是两个并发执行没有交集，互不影响的东西；当然实现中，也不一定需要这么完整隔离性，即不一定需要这么的互不干扰，有时候还是允许有部分干扰的。所以MySQL可以支持4种事务隔离性

持久性（Durability）：当某个 *** 作 *** 作完毕了，那么结果就是这样了，并且这个 *** 作会持久化到日志记录中

PS：ACID中C与CAP定理中C的区别

ACID的C着重强调单数据库事务 *** 作时，要保证数据的完整和正确性，数据不会凭空消失跟增加。CAP 理论中的C指的是对一个数据多个备份的读写一致性

事务 *** 作可能会出现的数据问题

1、脏读(dirty read)：B事务更改数据还未提交，A事务已经看到并且用了。B事务如果回滚，则A事务做错了

2、 不可重复读(non-repeatable read)：不可重复读的重点是修改: 同样的条件, 你读取过的数据, 再次读取出来发现值不一样了，只需要锁住满足条件的记录

3、 幻读(phantom read)：事务A先修改了某个表的所有纪录的状态字段为已处理，未提交；事务B也在此时新增了一条未处理的记录，并提交了；事务A随后查询记录，却发现有一条记录是未处理的造成幻读现象，幻读仅专指新插入的行。幻读会造成语义上的问题跟数据一致性问题。

4、 在可重复读RR隔离级别下，普通查询是快照读，是不会看到别的事务插入的数据的。因此，幻读在当前读下才会出现。要用间隙锁解决此问题。

在说隔离级别之前，你首先要知道，你隔离得越严实，效率就会越低。因此很多时候，我们都要在二者之间寻找一个平衡点。SQL标准的事务隔离级别由低到高如下： 上图从上到下的模式会导致系统的并行性能依次降低，安全性依次提高。

读未提交：别人改数据的事务尚未提交，我在我的事务中也能读到。

读已提交(Oracle默认)：别人改数据的事务已经提交，我在我的事务中才能读到。

可重复读(MySQL默认)：别人改数据的事务已经提交，我在我的事务中也不去读，以此保证重复读一致性。

串行：我的事务尚未提交，别人就别想改数据。

标准跟实现：上面都是关于事务的标准，但是每一种数据库都有不同的实现，比如MySQL InnDB 默认为RR级别，但是不会出现幻读。因为当事务A更新了所有记录的某个字段，此时事务A会获得对这个表的表锁，因为事务A还没有提交，所以事务A获得的锁没有释放，此时事务B在该表插入新记录，会因为无法获得该表的锁，则导致插入 *** 作被阻塞。只有事务A提交了事务后，释放了锁，事务B才能进行接下去的 *** 作。所以可以说 MySQL的RR级别的隔离是已经实现解决了脏读，不可重复读和幻读的。

5、MySQL中的锁

无论是Java的并发编程还是数据库的并发 *** 作都会涉及到锁，研发人员引入了悲观锁跟乐观锁这样一种锁的设计思想。

悲观锁：

优点：适合在写多读少的并发环境中使用，虽然无法维持非常高的性能，但是在乐观锁无法提更好的性能前提下，可以做到数据的安全性

缺点：加锁会增加系统开销，虽然能保证数据的安全，但数据处理吞吐量低，不适合在读书写少的场合下使用

乐观锁：

优点：在读多写少的并发场景下，可以避免数据库加锁的开销，提高DAO层的响应性能，很多情况下ORM工具都有带有乐观锁的实现，所以这些方法不一定需要我们人为的去实现。

缺点：在写多读少的并发场景下，即在写 *** 作竞争激烈的情况下，会导致CAS多次重试，冲突频率过高，导致开销比悲观锁更高。

实现：数据库层面的乐观锁其实跟CAS思想类似， 通数据版本号或者时间戳也可以实现。

数据库并发场景主要有三种：

读-读：不存在任何问题，也不需要并发控制

读-写：有隔离性问题，可能遇到脏读，幻读，不可重复读

写-写：可能存更新丢失问题，比如第一类更新丢失，第二类更新丢失

两类更新丢失问题：

第一类更新丢失：事务A的事务回滚覆盖了事务B已提交的结果 第二类更新丢失：事务A的提交覆盖了事务B已提交的结果

为了合理贯彻落实锁的思想，MySQL中引入了杂七杂八的各种锁：

锁分类

MySQL支持三种层级的锁定，分别为

表级锁定

MySQL中锁定粒度最大的一种锁，最常使用的MYISAM与INNODB都支持表级锁定。

页级锁定

是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁，表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。

行级锁定

Mysql中锁定粒度最细的一种锁，表示只针对当前 *** 作的行进行加锁。行级锁能大大减少数据库 *** 作的冲突。其加锁粒度最小，但加锁的开销也最大行级锁不一定比表级锁要好：锁的粒度越细，代价越高，相比表级锁在表的头部直接加锁，行级锁还要扫描找到对应的行对其上锁，这样的代价其实是比较高的，所以表锁和行锁各有所长。

MyISAM中的锁

虽然MySQL支持表，页，行三级锁定，但MyISAM存储引擎只支持表锁。所以MyISAM的加锁相对比较开销低，但数据 *** 作的并发性能相对就不高。但如果写 *** 作都是尾插入，那还是可以支持一定程度的读写并发

从MyISAM所支持的锁中也可以看出，MyISAM是一个支持读读并发，但不支持通用读写并发，写写并发的数据库引擎，所以它更适合用于读多写少的应用场合，一般工程中也用的较少。

InnoDB中的锁

该模式下支持的锁实在是太多了，具体如下：

共享锁和排他锁 (Shared and Exclusive Locks)

意向锁（Intention Locks）

记录锁（Record Locks）

间隙锁（Gap Locks）

临键锁 （Next-Key Locks）

插入意向锁（Insert Intention Locks）

主键自增锁 (AUTO-INC Locks)

空间索引断言锁（Predicate Locks for Spatial Indexes）

举个栗子，比如行锁里的共享锁跟排它锁：lock in share modle 共享读锁：

为了确保自己查到的数据没有被其他的事务正在修改，也就是说确保查到的数据是最新的数据，并且不允许其他人来修改数据。但是自己不一定能够修改数据，因为有可能其他的事务也对这些数据使用了 in share mode 的方式上了S 锁。如果不及时的commit 或者rollback 也可能会造成大量的事务等待。

for update排它写锁:

为了让自己查到的数据确保是最新数据，并且查到后的数据只允许自己来修改的时候，需要用到for update。相当于一个 update 语句。在业务繁忙的情况下，如果事务没有及时的commit或者rollback 可能会造成其他事务长时间的等待，从而影响数据库的并发使用效率。

Gap Lock间隙锁：

1、行锁只能锁住行，如果在记录之间的间隙插入数据就无法解决了，因此MySQL引入了间隙锁(Gap Lock)。间隙锁是左右开区间。间隙锁之间不会冲突。

2、间隙锁和行锁合称NextKeyLock，每个NextKeyLock是前开后闭区间。

间隙锁加锁原则(学完忘那种)：

1、加锁的基本单位是 NextKeyLock，是前开后闭区间。

2、查找过程中访问到的对象才会加锁。

3、索引上的等值查询，给唯一索引加锁的时候，NextKeyLock退化为行锁。

4、索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，NextKeyLock退化为间隙锁。

5、唯一索引上的范围查询会访问到不满足条件的第一个值为止。

MySQL 322 限制的表大小为4GB。由于在MySQL 323 中使用了MyISAM 存储引擎，最大表尺寸增加到了65536TB（2567 – 1字节）。由于允许的表尺寸更大，MySQL数据库的最大有效表尺寸通常是由 *** 作系统对文件大小的限制决定的，而不是由MySQL内部限制决定的。

InnoDB 存储引擎将InnoDB 表保存在一个表空间内，该表空间可由数个文件创建。这样，表的大小就能超过单独文件的最大容量。表空间可包括原始磁盘分区，从而使得很大的表成为可能。表空间的最大容量为64TB。

扩展资料

据DVB 团队以及Cmshelp 团队做CMS 系统评测时的结果来看，MySQL单表大约在2千万条记录（4G）下能够良好运行，经过数据库的优化后5千万条记录（10G）下运行良好。

这对于MySQL是不公平的，那些CMS厂商非但没有把内核做好反而还在添加很多花哨的功能，最终导致其产品自身负载过低。

他们并没有针对自身负载效果作出相应的数据库优化方案及标准，而是继续保留着复杂的结构造成对MySQL的资源无休止的浪费，最终导致了其负载上的缺陷。

于是他们便充分发挥中国人的传统优势——变通：避重就轻的采用了所谓的分表式存储，虽然在一定程度上缓解了自身负载的缺陷，但是导致了网站后期维护以及资源上的浪费。

用一个不恰当的比喻来形容，MySQL中的的表就像一块地，单表就相当于利用这块地盖高层建筑充分利用达到高人员负载，但分表就相当于用这块地盖了一间平房。

如果为了达到高人员负载的话那就需要另开地皮达到目的，但是我们要思考，是地不够，还是他的能力不够，如此做法让人感到资源的浪费以及规划的严重缺陷。

数据库优化是系统工程，性能的提升靠整体。本课程将面面俱到的讲解提升数据库性能的各种因素，让你在最短的时间从小白到资深，将数据库整体架构了然于胸

第1章 实例和故事 试看7 节 | 50分钟

决定电商11大促成败的各个关键因素。

收起列表

视频：1-1 什么决定了电商双11大促的成败 (04:04)试看

视频：1-2 在双11大促中的数据库服务器 (06:03)

视频：1-3 在大促中什么影响了数据库性能 (07:55)

视频：1-4 大表带来的问题 (14:13)

视频：1-5 大事务带来的问题 (17:27)

作业：1-6 讨论题在日常工作中如何应对高并发大数据量对数据库性能挑战

作业：1-7 讨论题在MySQL中事务的作用是什么？

第2章 什么影响了MySQL性能 试看30 节 | 210分钟

详细介绍影响性能各个因素，包括硬件、 *** 作系统等等。

收起列表

视频：2-1 影响性能的几个方面 (04:08)试看

视频：2-2 CPU资源和可用内存大小 (10:54)

视频：2-3 磁盘的配置和选择 (04:44)

视频：2-4 使用RAID增加传统机器硬盘的性能 (11:30)

视频：2-5 使用固态存储SSD或PCIe卡 (08:35)

视频：2-6 使用网络存储SAN和NAS (07:16)

视频：2-7 总结：服务器硬件对性能的影响 (03:27)

视频：2-8 *** 作系统对性能的影响-MySQL适合的 *** 作系统 (03:50)

视频：2-9 CentOS系统参数优化 (11:43)

视频：2-10 文件系统对性能的影响 (03:29)

视频：2-11 MySQL体系结构 (05:29)

视频：2-12 MySQL常用存储引擎之MyISAM (13:23)

视频：2-13 MySQL常用存储引擎之Innodb (10:44)

视频：2-14 Innodb存储引擎的特性(1) (15:24)

视频：2-15 Innodb存储引擎的特性(2) (08:44)

视频：2-16 MySQL常用存储引擎之CSV (09:19)

视频：2-17 MySQL常用存储引擎之Archive (06:08)

视频：2-18 MySQL常用存储引擎之Memory (10:40)

视频：2-19 MySQL常用存储引擎之Federated (11:21)

视频：2-20 如何选择存储引擎 (04:33)

视频：2-21 MySQL服务器参数介绍 (08:04)

视频：2-22 内存配置相关参数 (09:24)

视频：2-23 IO相关配置参数 (10:01)

视频：2-24 安全相关配置参数 (06:13)

视频：2-25 其它常用配置参数 (03:41)

视频：2-26 数据库设计对性能的影响 (04:36)

视频：2-27 总结 (01:32)

作业：2-28 讨论题你会如何配置公司的数据库服务器硬件？

作业：2-29 讨论题你认为对数据库性能影响最大的因素是什么

作业：2-30 讨论题做为电商的DBA，建议开发选哪种MySQL存储引擎

第3章 MySQL基准测试8 节 | 65分钟

了解基准测试,MySQL基准测试工具介绍及实例演示。

收起列表

视频：3-1 什么是基准测试 (02:20)

视频：3-2 如何进行基准测试 (09:00)

视频：3-3 基准测试演示实例 (11:18)

视频：3-4 Mysql基准测试工具之mysqlslap (13:30)

视频：3-5 Mysql基准测试工具之sysbench (11:07)

视频：3-6 sysbench基准测试演示实例 (17:11)

作业：3-7 讨论题MySQL基准测试是否可以体现出业务系统的真实性能

作业：3-8 实 *** 题参数不同取值对性能的影响

第4章 MySQL数据库结构优化14 节 | 85分钟

详细介绍数据库结构设计、范式和反范式设计、物理设计等等。

收起列表

视频：4-1 数据库结构优化介绍 (06:52)

视频：4-2 数据库结构设计 (14:49)

视频：4-3 需求分析及逻辑设计 (11:00)

视频：4-4 需求分析及逻辑设计-反范式化设计 (06:44)

视频：4-5 范式化设计和反范式化设计优缺点 (04:06)

视频：4-6 物理设计介绍 (05:17)

视频：4-7 物理设计-数据类型的选择 (18:59)

视频：4-8 物理设计-如何存储日期类型 (13:37)

视频：4-9 物理设计-总结 (02:37)

图文：4-10 说明MyISAM和Innodb存储引擎的5点不同

作业：4-11 讨论题判断表结构是否符合第三范式要求如不满足要如何修改

作业：4-12 实 *** 题请设计一个电商订单系统的数据库结构

作业：4-13 讨论题以下那个字段适合作为Innodb表的主建使用

作业：4-14 讨论题请为下表中的字段选择合适的数据类型

第5章 MySQL高可用架构设计 试看24 节 | 249分钟

详细介绍二进制日志及其对复制的影响、GTID的复制、MMM、MHA等等。

收起列表

视频：5-1 mysql复制功能介绍 (04:58)

视频：5-2 mysql二进制日志 (22:05)

视频：5-3 mysql二进制日志格式对复制的影响 (09:37)

视频：5-4 mysql复制工作方式 (03:08)

视频：5-5 基于日志点的复制 (20:06)

视频：5-6 基于GTID的复制 (22:32)

视频：5-7 MySQL复制拓扑 (13:58)

视频：5-8 MySQL复制性能优化 (09:23)

视频：5-9 MySQL复制常见问题处理 (08:31)

视频：5-10 什么是高可用架构 (14:09)

视频：5-11 MMM架构介绍 (08:09)

视频：5-12 MMM架构实例演示（上） (09:16)试看

视频：5-13 MMM架构实例演示（下） (18:55)

视频：5-14 MMM架构的优缺点 (08:01)

视频：5-15 MHA架构介绍 (10:02)

视频：5-16 MHA架构实例演示(1) (13:11)

视频：5-17 MHA架构实例演示(2) (16:54)

视频：5-18 MHA架构优缺点 (05:14)

视频：5-19 读写分离和负载均衡介绍 (11:42)

视频：5-20 MaxScale实例演示 (18:25)

作业：5-21 讨论题MySQL主从复制为什么会有延迟，延迟又是如何产生

作业：5-22 实 *** 题请为某互联网项目设计9999%MySQL架构

作业：5-23 讨论题如何给一个已经存在的主从复制集群新增一个从节点

作业：5-24 讨论题给你三台数据库服务器，你如何设计它的高可用架构

第6章 数据库索引优化8 节 | 65分钟

介绍BTree索引和Hash索引，详细介绍索引的优化策略等等。

收起列表

视频：6-1 Btree索引和Hash索引 (20:09)

视频：6-2 安装演示数据库 (01:19)

视频：6-3 索引优化策略（上） (17:33)

视频：6-4 索引优化策略（中） (13:02)

视频：6-5 索引优化策略（下） (12:30)

作业：6-6 讨论题一列上建立了索引，查询时就一定会用到这个索引吗

作业：6-7 讨论题在定义联合索引时为什么需要注意联合索引中的顺序

作业：6-8 实 *** 题SQL建立索引，你会考虑那些因素

第7章 SQL查询优化9 节 | 62分钟

详细介绍慢查询日志及示例演示,MySQL查询优化器介绍及特定SQL的查询优化等。

收起列表

视频：7-1 获取有性能问题SQL的三种方法 (05:14)

视频：7-2 慢查询日志介绍 (08:57)

视频：7-3 慢查询日志实例 (08:27)

视频：7-4 实时获取性能问题SQL (02:21)

视频：7-5 SQL的解析预处理及生成执行计划 (16:02)

视频：7-6 如何确定查询处理各个阶段所消耗的时间 (09:35)

视频：7-7 特定SQL的查询优化 (10:34)

作业：7-8 讨论题如何跟据需要对一个大表中的数据进行删除或更新

作业：7-9 讨论题如何获取需要优化的SQL查询

第8章 数据库的分库分表5 节 | 48分钟

详细介绍数据库分库分表的实现原理及演示案例等。

收起列表

视频：8-1 数据库分库分表的几种方式 (04:34)

视频：8-2 数据库分片前的准备 (13:53)

视频：8-3 数据库分片演示(上) (11:40)

视频：8-4 数据库分片演示(下) (17:02)

作业：8-5 讨论题对于大表来说我们一定要进行分库分表吗

第9章 数据库监控7 节 | 29分钟

介绍数据库可用性监控、性能监控、MySQL主从复制监控等

收起列表

视频：9-1 数据库监控介绍 (04:46)

视频：9-2 数据库可用性监控 (07:20)

视频：9-3 数据库性能监控 (09:39)

视频：9-4 MySQL主从复制监控 (06:16)

作业：9-5 讨论题QPS是否可以真实的反映出数据库的负载情况

作业：9-6 讨论题如何正确评估数据库的当前负载状况

作业：9-7 实 *** 题开发一个简单监控脚本，监控mySQL数据库阻塞情况

in子查询、exists子查询、连接，效率的探讨

以下是SQL的帮助 （高级查询优化概念）

Microsoft® SQL Server™ 2000 使用内存中的排序和哈希联接技术执行排序、交集、联合、差分等 *** 作。SQL Server 利用这种类型的查询计划支持垂直表分区，有时称其为分列存储。

SQL Server 使用三种类型的联接 *** 作：

嵌套循环联接

合并联接

哈希联接

如果一个联接输入很小（比如不到 10 行），而另一个联接输入很大而且已在其联接列上创建索引，则索引嵌套循环是最快的联接 *** 作，因为它们需要最少的 I/O 和最少的比较。有关嵌套循环的更多信息，请参见了解嵌套循环联接。

如果两个联接输入并不小但已在二者联接列上排序（例如，如果它们是通过扫描已排序的索引获得的），则合并联接是最快的联接 *** 作。如果两个联接输入都很大，而且这两个输入的大小差不多，则预先排序的合并联接提供的性能与哈希联接相似。然而，如果两个输入的大小相差很大，则哈希联接 *** 作通常快得多。有关更多信息，请参见了解合并联接。

哈希联接可以有效处理很大的、未排序的非索引输入。它们对复杂查询的中间结果很有用，因为：

中间结果未经索引（除非已经显式保存到磁盘上然后创建索引），而且生成时通常不为查询计划中的下一个 *** 作进行适当的排序。

查询优化器只估计中间结果的大小。由于估计的值在复杂查询中可能有很大的误差，因此如果中间结果比预期的大得多，则处理中间结果的算法不仅必须有效而且必须适度弱化。

哈希联接使得对非规范化的使用减少。非规范化一般通过减少联接 *** 作获得更好的性能，尽管这样做有冗余之险（如不一致的更新）。哈希联接则减少使用非规范化的需要。哈希联接使垂直分区（用单独的文件或索引代表单个表中的几组列）得以成为物理数据库设计的可行选项。有关更多信息，请参见了解哈希联接。

影响数据检索效率的几个因素

数据检索有两种主要形态。第一种是纯数据库型的。典型的结构是一个关系型数据，比如 mysql。用户通过 SQL 表达出所需要的数据，mysql 把 SQL 翻译成物理的数据检索动作返回结果。第二种形态是现在越来越流行的大数据玩家的玩法。典型的结构是有一个分区的数据存储，最初这种存储就是原始的 HDFS，后来开逐步有人在 HDFS 上加上索引的支持，或者干脆用 Elasticsearc 这样的数据存储。然后在存储之上有一个分布式的实时计算层，比如 Hive 或者 Spark SQL。用户用 Hive SQL 提交给计算层，计算层从存储里拉取出数据，进行计算之后返回给用户。这种大数据的玩法起初是因为 SQL 有很多 ad-hoc 查询是满足不了的，干脆让用户自己写 map/reduce 想怎么算都可以了。但是后来玩大了之后，越来越多的人觉得这些 Hive 之类的方案查询效率怎么那么低下啊。于是一个又一个项目开始去优化这些大数据计算框架的查询性能。这些优化手段和经典的数据库优化到今天的手段是没有什么两样的，很多公司打着搞计算引擎的旗号干着重新发明数据库的活。所以，回归本质，影响数据检索效率的就那么几个因素。我们不妨来看一看。

数据检索干的是什么事情

定位 => 加载 => 变换

找到所需要的数据，把数据从远程或者磁盘加载到内存中。按照规则进行变换，比如按某个字段group by，取另外一个字段的sum之类的计算。

影响效率的四个因素

读取更少的数据

数据本地化，充分遵循底层硬件的限制设计架构

更多的机器

更高效率的计算和计算的物理实现

原则上的四点描述是非常抽象的。我们具体来看这些点映射到实际的数据库中都是一些什么样的优化措施。

读取更少的数据

数据越少，检索需要的时间当然越少了。在考虑所有技术手段之前，最有效果的恐怕是从业务的角度审视一下我们是否需要从那么多的数据中检索出结果来。有没有可能用更少的数据达到同样的效果。减少的数据量的两个手段，聚合和抽样。如果在入库之前把数据就做了聚合或者抽样，是不是可以极大地减少查询所需要的时间，同时效果上并无多少差异呢？极端情况下，如果需要的是一天的总访问量，比如有1个亿。查询的时候去数1亿行肯定快不了。但是如果统计好了一天的总访问量，查询的时候只需要取得一条记录就可以知道今天有1个亿的人访问了。

索引是一种非常常见的减少数据读取量的策略了。一般的按行存储的关系型数据库都会有一个主键。用这个主键可以非常快速的查找到对应的行。KV存储也是这样，按照Key可以快速地找到对应的Value。可以理解为一个Hashmap。但是一旦查询的时候不是用主键，而是另外一个字段。那么最糟糕的情况就是进行一次全表的扫描了，也就是把所有的数据都读取出来，然后看要的数据到底在哪里，这就不可能快了。减少数据读取量的最佳方案就是，建立一个类似字典一样的查找表，当我们找 username=wentao 的时候，可以列举出所有有 wentao 作为用户名的行的主键。然后拿这些主键去行存储（就是那个hashmap）里捞数据，就一捞一个准了。

谈到索引就不得不谈一下一个查询使用了两个字段，如何使用两个索引的问题。mysql的行为可以代表大部分主流数据库的处理方式：

基本上来说，经验表明有多个单字段的索引，最后数据库会选一最优的来使用。其余字段的过滤仍然是通过数据读取到内存之后，用predicate去判断的。也就是无法减少数据的读取量。

在这个方面基于inverted index的数据就非常有特点。一个是Elasticsearch为代表的lucene系的数据库。另外一个是新锐的druid数据库。

效果就是，这些数据库可以把单字段的filter结果缓存起来。多个字段的查询可以把之前缓存的结果直接拿过来做 AND 或者 OR *** 作。

索引存在的必要是因为主存储没有提供直接的快速定位的能力。如果访问的就是数据库的主键，那么需要读取的数据也就非常少了。另外一个变种就是支持遍历的主键，比如hbase的rowkey。如果查询的是一个基于rowkey的范围，那么像hbase这样的数据库就可以支持只读取到这个范围内的数据，而不用读取不再这个范围内的额外数据，从而提高速度。这种加速的方式就是利用了主存储自身的物理分布的特性。另外一个更常见的场景就是 partition。比如 mysql 或者 postgresql 都支持分区表的概念。当我们建立了分区表之后，查找的条件如果可以过滤出分区，那么可以大幅减少需要读取的数据量。比 partition 更细粒度一些的是 clustered index。它其实不是一个索引（二级索引），它是改变了数据在主存储内的排列方式，让相同clustered key的数据彼此紧挨着放在一起，从而在查询的时候避免扫描到无关的数据。比 partition 更粗一些的是分库分表分文件。比如我们可以一天建立一张表，查询的时候先定位到表，再执行 SQL。比如 graphite 给每个 metric 创建一个文件存放采集来的 data point，查询的时候给定metric 就可以定位到一个文件，然后只读取这个文件的数据。

另外还有一点就是按行存储和按列存储的区别。按列存储的时候，每个列是一个独立的文件。查询用到了哪几个列就打开哪几个列的文件，没有用到的列的数据碰都不会碰到。反观按行存储，一张中的所有字段是彼此紧挨在磁盘上的。一个表如果有100个字段，哪怕只选取其中的一个字段，在扫描磁盘的时候其余99个字段的数据仍然会被扫描到的。

考虑一个具体的案例，时间序列数据。如何使用读取更少的数据的策略来提高检索的效率呢？首先，我们可以保证入库的时间粒度，维度粒度是正好是查询所需要的。如果查询需要的是5分钟数据，但是入库的是1分钟的，那么就可以先聚合成5分钟的再存入数据库。对于主存储的物理布局选择，如果查询总是针对一个时间范围的。那么把 timestamp 做为 hbase 的 rowkey，或者 mysql 的 clustered index 是合适。这样我们按时间过滤的时候，选择到的是一堆连续的数据，不用读取之后再过滤掉不符合条件的数据。但是如果在一个时间范围内有很多中数据，比如1万个IP，那么即便是查1个IP的数据也需要把1万个IP的数据都读取出来。所以可以把 IP 维度也编码到 rowkey 或者 clustered index 中。但是假如另外还有一个维度是 OS，那么查询的时候 IP 维度的 rowkey 是没有帮助的，仍然是要把所有的数据都查出来。这就是仅依靠主存储是无法满足各种查询条件下都能够读取更少的数据的原因。所以，二级索引是必要的。我们可以把时间序列中的所有维度都拿出来建立索引，然后查询的时候如果指定了维度，就可以用二级索引把真正需要读取的数据过滤出来。但是实践中，很多数据库并不因为使用了索引使得查询变快了，有的时候反而变得更慢了。对于 mysql 来说，存储时间序列的最佳方式是按时间做 partition，不对维度建立任何索引。查询的时候只过滤出对应的 partition，然后进行全 partition 扫描，这样会快过于使用二级索引定位到行之后再去读取主存储的查询方式。究其原因，就是数据本地化的问题了。

[page]

数据本地化

数据本地化的实质是软件工程师们要充分尊重和理解底层硬件的限制，并且用各种手段规避问题最大化利用手里的硬件资源。本地化有很多种形态

最常见的最好理解的本地化问题是网络问题。我们都知道网络带宽不是无限的，比本地磁盘慢多了。如果可能尽量不要通过网络去访问数据。即便要访问，也应该一次抓取多一些数据，而不是一次搞一点，然后搞很多次。因为网络连接和来回的开销是非常高的。这就是 data locality 的问题。我们要把计算尽可能的靠近数据，减少网络上传输的数据量。

这种带宽引起的本地化问题，还有很多。网络比硬盘慢，硬盘比内存慢，内存比L2缓存慢。做到极致的数据库可以让计算完全发生在 L2 缓存内，尽可能地避免频繁地在内存和L2之间倒腾数据。

另外一种形态的问题化问题是磁盘的顺序读和随机读的问题。当数据彼此靠近地物理存放在磁盘上的时候，顺序读取一批是非常快的。如果需要随机读取多个不连续的硬盘位置，磁头就要来回移动从而使得读取速度快速下降。即便是 SSD 硬盘，顺序读也是要比随机读快的。

基于尽可能让数据读取本地化的原则，检索应该尽可能地使用顺序读而不是随机读。如果可以的话，把主存储的row key或者clustered index设计为和查询提交一样的。时间序列如果都是按时间查，那么按时间做的row key可以非常高效地以顺序读的方式把数据拉取出来。类似地，按列存储的数据如果要把一个列的数据都取出来加和的话，可以非常快地用顺序读的方式加载出来。

二级索引的访问方式典型的随机读。当查询条件经过了二级索引查找之后得到一堆的主存储的 key，那么就需要对每个 key 进行一次随机读。即便彼此仅靠的key可以用顺序读做一些优化，总体上来说仍然是随机读的模式。这也就是为什么时间序列数据在 mysql 里建立了索引反而比没有建索引还要慢的原因。

为了尽可能的利用顺序读，人们就开始想各种办法了。前面提到了 mysql 里的一行数据的多个列是彼此紧靠地物理存放的。那么如果我们把所需要的数据建成多个列，那么一次查询就可以批量获得更多的数据，减少随机读取的次数。也就是把之前的一些行变为列的方式来存放，减少行的数量。这种做法的经典案例就是时间序列数据，比如可以一分钟存一行数据，每一秒的值变成一个列。那么行的数量可以变成之前的1/60。

但是这种行变列的做法在按列存储的数据库里就不能直接照搬了，有些列式数据库有column family的概念，不同的设置在物理上存放可能是在一起的也可能是分开的。对于 Elasticsearch 来说，要想减少行的数量，让一行多pack一些数据进去，一种做法就是利用 nested document。内部 Elasticsearch 可以保证一个 document 下的所有的 nested document是物理上靠在一起放在同一个 lucene 的 segment 内。

网络的data locality就比较为人熟知了。map reduce的大数据计算模式就是利用map在数据节点的本地把数据先做一次计算，往往计算的结果可以比原数据小很多。然后再通过网络传输汇总后做 reduce 计算。这样就节省了大量网络传输数据的时间浪费和资源消耗。现在 Elasticsearch 就支持在每个 data node 上部署 spark。由 spark 在每个 data node 上做计算。而不用把数据都查询出来，用网络传输到 spark 集群里再去计算。这种数据库和计算集群的混合部署是高性能的关键。类似的还有 storm 和 kafka 之间的关系。

网络的data locality还有一个老大难问题就是分布式大数据下的多表join问题。如果只是查询一个分布式表，那么把计算用 map reduce 表达就没有多大问题了。但是如果需要同时查询两个表，就意味着两个表可能不是在物理上同样均匀分布的。一种最简单的策略就是找出两张表中最小的那张，然后把表的内容广播到每个节点上，再做join。复杂一些的是对两个单表做 map reduce，然后按照相同的 key 把部分计算的结果汇集在一起。第三种策略是保证数据分布的方式，让两张表查询的时候需要用到的数据总在一起。没有完美的方案，也不大可能有完美的方案。除非有一天网络带宽可以大到忽略不计的地步。

更多的机器

这个就没有什么好说的了。多一倍的机器就多一倍的 CPU，可以同时计算更多的数据。多一倍的机器就多一倍的磁头，可以同时扫描更多的字节数。很多大数据框架的故事就是讲如何如何通过 scale out解决无限大的问题。但是值得注意的是，集群可以无限大，数据可以无限多，但是口袋里的银子不会无限多的。堆机器解决问题比升级大型机是要便宜，但是机器堆多了也是非常昂贵的。特别是 Hive 这些从一开始就是分布式多机的检索方案，刚开始的时候效率并不高。堆机器是一个乘数，当数据库本来单机性能不高的时候，乘数大并不能起到决定性的作用。

更高效的计算和计算实现

检索的过程不仅仅是磁盘扫描，它还包括一个可简单可复杂的变换过程。使用 hyperloglog，count min-sketch等有损算法可以极大地提高统计计算的性能。数据库的join也是一个经常有算法创新的地方。

计算实现就是算法是用C++实现的还是用java，还是python实现的。用java是用大Integer实现的，还是小int实现的。不同的语言的实现方式会有一些固定的开销。不是说快就一定要C++，但是 python 写 for 循环是显然没有指望的。任何数据检索的环节只要包含 python/ruby 这些语言的逐条 for 循环就一定快不起来了。

结论

希望这四点可以被记住，成为一种指导性的优化数据检索效率的思维框架。无论你是设计一个mysql表结构，还是优化一个spark sql的应用。从这四个角度想想，都有哪些环节是在拖后腿的，手上的工具有什么样的参数可以调整，让随机读变成顺序读，表结构怎么样设计可以最小化数据读取的量。要做到这一点，你必须非常非常了解工具的底层实现。而不是盲目的相信，xx数据库是最好的数据库，所以它一定很快之类的。如果你不了解你手上的数据库或者计算引擎，当它快的时候你不知道为何快，当它慢的时候你就更加无从优化了。

mysql自己和自己比较的方法:

1首先具体的服务器软件,如果是中小企业,主流选择是linux *** 作系统和mysql数据库,我就拿这个做比较。区别主要在于性能上。自己安装的mysql是开源版本,而云数据库是云厂家在开源的mysql上进行了性能优化的。

2

其次在运维的便捷上。自己安装的mysql数据库,需要考虑安全性,数据库备份策略,如果业务并发高,还得考虑读者分离,甚至分库分表的策略。

以上就是关于mysql 核心内容-上全部的内容，包括:mysql 核心内容-上、mysql 数据库可以有多大、扛得住的MySQL数据库架构等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！