提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

前言
一、知识体系
二、Mysql-优化
- [1. 优化-如何定位慢查询](#1. 优化-如何定位慢查询)
- - [① 问题引入](#① 问题引入)
  - [② 解决方案](#② 解决方案)
  - [③ 问题总结](#③ 问题总结)
  - [④ 实战面试](#④ 实战面试)
- [2. 优化-sql执行很慢，如何解决](#2. 优化-sql执行很慢，如何解决)
- - [① 问题引入](#① 问题引入)
  - [② 解决方案](#② 解决方案)
  - [③ 问题总结](#③ 问题总结)
  - [④ 实战面试](#④ 实战面试)
- [3. 优化-索引概念](#3. 优化-索引概念)
- - [① 问题引入](#① 问题引入)
  - [② 数据结构对比](#② 数据结构对比)
  - [③ 问题总结](#③ 问题总结)
  - [④ 实战面试](#④ 实战面试)
- [4. 优化-聚簇索引与非聚簇索引](#4. 优化-聚簇索引与非聚簇索引)
- - [① 问题引入](#① 问题引入)
  - [② 聚簇索引](#② 聚簇索引)
  - [③ 问题总结](#③ 问题总结)
  - [④ 实战面试](#④ 实战面试)
- [5. 优化-覆盖索引](#5. 优化-覆盖索引)
- - [① 问题引入](#① 问题引入)
  - [② 覆盖索引](#② 覆盖索引)
  - [③ Mysql超大分页处理](#③ Mysql超大分页处理)
  - [④ 问题总结](#④ 问题总结)
  - [⑤ 实战面试](#⑤ 实战面试)
- [6. 优化-索引创建的原则](#6. 优化-索引创建的原则)
- - [① 问题引入](#① 问题引入)
  - [② 索引创建的原则](#② 索引创建的原则)
  - [③ 问题总结](#③ 问题总结)
  - [④ 实战面试](#④ 实战面试)
- [7. 优化-什么情况下索引会失效](#7. 优化-什么情况下索引会失效)
- - [① 问题引入](#① 问题引入)
  - [② 什么情况下索引会失效](#② 什么情况下索引会失效)
  - [③ 问题总结](#③ 问题总结)
  - [④ 实战面试](#④ 实战面试)
- [8. 优化-SQL优化的经验](#8. 优化-SQL优化的经验)
- - [① 问题引入](#① 问题引入)
  - [② sql优化经验](#② sql优化经验)
  - [③ 问题总结](#③ 问题总结)
  - [④ 实战面试](#④ 实战面试)
三、Mysql-其他面试题
- [1. 事务的特性ACID](#1. 事务的特性ACID)
- - [① 问题引入](#① 问题引入)
  - [② ACID是什么](#② ACID是什么)
  - [③ 问题总结](#③ 问题总结)
  - [④ 实战面试](#④ 实战面试)
- [2. 并发事务](#2. 并发事务)
- - [① 问题引入](#① 问题引入)
  - [② 并发事务问题](#② 并发事务问题)
  - [③ 事务隔离](#③ 事务隔离)
  - [④ 问题总结](#④ 问题总结)
  - [⑤ 实战面试](#⑤ 实战面试)
- [3. 事务-undo log和redo log的区别](#3. 事务-undo log和redo log的区别)
- - [① 问题引入](#① 问题引入)
  - [② redo log重做日志](#② redo log重做日志)
  - [③ undo log回滚日志](#③ undo log回滚日志)
  - [④ 问题总结](#④ 问题总结)
  - [⑤ 实战面试](#⑤ 实战面试)
- [4. 事务-MVCC多版本并发控制（难）](#4. 事务-MVCC多版本并发控制（难）)
- - [① 问题引入](#① 问题引入)
  - [② MVCC多版本并发控制](#② MVCC多版本并发控制)
  - [③ 问题总结](#③ 问题总结)
  - [④ 实战面试](#④ 实战面试)
- [5. Mysql主从同步原理](#5. Mysql主从同步原理)
- - [① 问题引入](#① 问题引入)
  - [② 主从同步原理](#② 主从同步原理)
  - [③ 问题总结](#③ 问题总结)
  - [④ 实战面试](#④ 实战面试)
- [6. Mysql分库分表](#6. Mysql分库分表)
- - [① 问题引入](#① 问题引入)
  - [② 拆分策略](#② 拆分策略)
  - [③ 问题总结](#③ 问题总结)
引用说明

前言

本文主要记录mysql的查询、索引、sql优化、事务、主从同步、分库分表等问题的分析与面试回答示例。

提示：以下是本篇文章正文内容，下面案例可供参考

一、知识体系

二、Mysql-优化

1. 优化-如何定位慢查询

① 问题引入

聚合查询
多表查询
表数据量过大查询
深度分页查询

表象：页面加载过慢、接口压测响应时间过长（超过1s)

② 解决方案

方案一：开源工具

调试工具：Arthas

运维工具：Prometheus 、Skywalking

方案二：Mysql自带慢日志

慢查询日志记录了所有执行时间超过指定参数(long_query_time，单位:秒，默认10秒）的所有SQL语句的日志如果要开启慢查询日志，需要在MySQL的配置文件(/etc/my.cnf)中配置如下信息：

配置完毕之后，通过以下指令重新启动MySQL服务器进行测试，查看慢日志文件中记录的信息/var/lib/mysql/localhost-slow.log

③ 问题总结

④ 实战面试

2. 优化-sql执行很慢，如何解决

① 问题引入

聚合查询：新增临时表
多表查询：优化sql语句结构
表数据量过大查询：添加索引
深度分页查询

② 解决方案

一个SQL语句执行很慢，如何分析？

可以采用EXPLAIN 或者DESC命令获取MySQL如何执行SELECT语句的信息

展示SQL执行的情况，部分字段说明如下：

possible_key 当前sql可能会使用到的索引
key 当前sql实际命中的索引
key_len 索引占用的大小
Extra 额外的优化建议
type这条sql的连接的类型，性能由好到差为NULL、system、const、 eq_ref、ref、range、index、all
system：查询系统中的表
const：根据主键查询（常用）
eq_ref：sql的查询条件是主键索引查询或唯一索引查询（返回一条数据）
ref：sql的查询条件是索引查询（返回多条数据）
range：索引范围查询
index：全索引查询，遍历整个索引数，效率不高（需要优化）
all：全盘扫描（需要优化）

③ 问题总结

可以采用MySQL自带的分析工具EXPLAIN

通过key和key_len检查是否命中了索引(索引本身存在是否有失效的情况)
通过type字段查看sql是否有进一步的优化空间，是否存在全索引扫描或全盘扫描
通过extra建议判断，是否出现了回表的情况，如果出现了，可以尝试添加索引或修改返回字段来修复

④ 实战面试

3. 优化-索引概念

① 问题引入

索引(index) 是帮助MySQL高效获取数据的数据结构(有序)。在数据之外，数据库系统还维护着满足特定查找算法的数据结构（B+树)，这些数据结构以某种方式引用 (指向）数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

维护树的数据结构，提高查找效率，减少IO的操作

B+树、二叉树、红黑树、B树

② 数据结构对比

MySQL默认使用的索引底层数据结构是B+树。再聊B+树之前，我们先聊聊二叉树和B树

B-Tree ，B树是一种多叉路衡查找树，相对于二叉树，B树每个节点可以有多个分支，即多叉。以一颗最大度数(max-degree)为5(5阶)的b-tree为例，那这个B树每个节点最多存储4个key

B+Tree 是在BTree基础上的一种优化，使其更适合实现外存储索引结构，InnoDB存储引擎就是用B+Tree实现其索引结构

B树与B+树对比:

磁盘读写代价B+树更低（非叶子节点不存储数据）;
查询效率B+树更加稳定（数据都存储在叶子节点）;
B+树便于扫库和区间查询（叶子节点之间使用的双向指针）

③ 问题总结

④ 实战面试

4. 优化-聚簇索引与非聚簇索引

① 问题引入

什么是聚集索引
什么是二级索引（非聚集索引)
什么是回表?

② 聚簇索引

聚集索引选取规则:

1.如果存在主键，主键索引就是聚集索引。

2.如果不存在主键，将使用第一个唯一(UNIQUE)索引作为聚集索引。

3.如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引。

回表查询：先通过二级索引找到对应的主键值，在用主键值在聚集索引中去找整行的数据

③ 问题总结

④ 实战面试

5. 优化-覆盖索引

① 问题引入

覆盖索引 是指查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到。

判断下面的SQL哪些是覆盖索引，为什么？

sql 复制代码

select * from tb_user where id = 1
是，因为根据id查询的，id默认是主键索引，就是聚簇索引，聚簇索引中对应的是整行的记录

select id，name from tb_user where name = 'Arm'
是，因为通过name这个二级索引也可以找到id，是一次性可以查询出来id和name的

select id,name，gender from tb_user where name = 'Arm'
不是，需要通过回表查询才能获取到gender

② 覆盖索引

覆盖索引是指查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到。

③ Mysql超大分页处理

在数据量比较大时，如果进行limit分页查询，在查询时，越往后，分页查询效率越低。

我们一起来看看执行limit分页查询耗时对比:
因为，当在进行分页查询时，如果执行limit 9000000,10，此时需要MySQL排序前9000010记录，仅仅返回9000000 - 9000010 的记录，其他记录丢弃，查询排序的代价非常大。

优化思路：

一般分页查询时，通过创建覆盖索引能够比较好地提高性能，可以通过覆盖索引加子查询形式进行优化

④ 问题总结

⑤ 实战面试

6. 优化-索引创建的原则

① 问题引入

先陈述自己在实际的工作中是怎么用的

主键索引

唯一索引

根据业务创建的索引(复合索引)

② 索引创建的原则

针对于数据量较大 ，且查询比较频繁 的表建立索引。单表超过10万数据 (增加用户体验)
针对于常作为查询条件 (where)、排序（order by)、分组 (group by) 操作的字段建立索引。
尽量选择区分度高的列 作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高（比如一个地区字段，大部分都是北京市，就不适合创建索引）。
如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引 （比如简介内容想要创建索引，就采用前缀索引）。
尽量使用联合索引，减少单列索引，查询时，联合索引 很多时候可以覆盖索引 ，节省存储空间，避免回表，提高查询效率。
要控制索引的数量，索引并不是多多益善，索引越多 ，维护索引 结构的代价也就越大 ，会影响增删改的效率。
如果索引列不能存储NULL值 ，请在创建表 时使用NOT NULL约束它。当优化器知道每列是否包含NULL值时，它可以更好地确定哪个索引最有效地用于查询。

③ 问题总结

④ 实战面试

7. 优化-什么情况下索引会失效

① 问题引入

索引失效的情况有很多，可以说一些自己遇到过的。

给tb_seller创建联合索引，字段顺序: name,status,address

那快读判断索引是否失效了呢?执行计划explain

② 什么情况下索引会失效

违反最左前缀法则

如果索引了多列，要遵守最左前缀法则 。指的是查询从索引的最左前列开始，并且不跳过索引中的列。匹配最左前缀法则，走索引。

有效的情况如下图所示：

失效的情况如下图所示（违反最左前缀法则）：
范围查询右边的列，不能使用索引。

根据前面的两个字段name , status查询是走索引的，但是最后一个条件address没有用到索引。
不要在索引列上进行运算操作 ，索引将失效。
字符串不加单引号，造成索引失效。

由于，在查询是，没有对字符串加单引号，MySQL的查询优化器，会自动的进行类型转换 ，造成索引失效。
以%开头的Like模糊查询，索引失效。如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。

③ 问题总结

④ 实战面试

8. 优化-SQL优化的经验

① 问题引入

表的设计优化

索引优化（参考优化创建原则和索引失效）

SQL语句优化

主从复制、读写分离

分库分表

② sql优化经验

表的设计优化(参考阿里开发手册《嵩山版》)
a. 比如设置合适的数值 (tinyint int bigint)，要根据实际情况选择
b. 比如设置合适的字符串类型(char和varchar) char定长效率高.varchar可变长度，效率稍低
SQL语句 优化
a. SELECT语句务必指明字段名称 （避免直接使用select* )
b. SQL语句要避免造成索引失效 的写法
c. 尽量用union all 代替union，union会多一次过滤，效率低
d. 避免在where子句中对字段进行表达式操作
e. Join优化能用inner join就不用left join right join，如必须使用一定要以小表为驱动，内连接会对两个表进行优化，优先把小表放到外边，把大表放到里边。left join或right join，不会重新调整顺序
主从复制、读写分离
如果数据库的使用场景读的操作比较多 的时候，为了避免写的操作所造成的性能影响可以采用读写分离的架构。
读写分离解决的是，数据库的写入，影响了查询的效率 。

③ 问题总结

④ 实战面试

三、Mysql-其他面试题

1. 事务的特性ACID

① 问题引入

事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败。

② ACID是什么

原子性(Atomicity) :事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
一致性(Consistency) :事务完成时，必须使所有的数据都保持一致状态。
隔离性(Isolation) :数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。
持久性(Durability) :事务一旦提交或回滚，它对数据库中的数据的改变就是永久的 。

③ 问题总结

④ 实战面试

2. 并发事务

① 问题引入

● 并发事务问题：脏读、不可重复读、幻读

● 隔离级别：读未提交、读已提交、可重复读、串行化

② 并发事务问题

脏读：一个事务读到另外一个事务还没有提交的数据。
不可重复读：一个事务先后读取同一条记录，但两次读取的数据不同，称之为不可重复读。
幻读：一个事务按照条件查询数据时，没有对应的数据行，但是在插入数据时，又发现这行数据已经存在，好像出现了"幻影"。

③ 事务隔离

对并发事务进行隔离，有以下隔离级别，如下图所示：

注意：事务隔离级别越高，数据越安全，但是性能越低。

④ 问题总结

⑤ 实战面试

3. 事务-undo log和redo log的区别

① 问题引入

undo log和redo log都是mysql的日志文件，但是功能不一样。

缓冲池（buffer pool）：主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据(若缓冲池没有数据，则从磁盘加载并缓存)，以一定频率刷新到磁盘，从而减少磁盘IO,加快处理速度
数据页 （page）：是InnoDB 存储引擎磁盘管理 的最小单元，每个页的大小默认为16KB。页中存储的是行数据

② redo log重做日志

redo log 重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性 。

该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log file），前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中，用于在刷新脏页到磁盘，发生错误时，进行数据恢复使用 。（每个一段时间会进行清理）

③ undo log回滚日志

undo log 回滚日志，用于记录数据被修改前的信息，作用包含两个：提供回滚 和MVCC (多版本并发控制)。undo log和redo log记录物理日志不一样，它是逻辑日志。

可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然,
当update一条记录时, 它记录一条对应相反的update记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
undo log可以实现事务的一致性和原子性

④ 问题总结

⑤ 实战面试

4. 事务-MVCC多版本并发控制（难）

① 问题引入

锁：排他锁(如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁)

mvcc：多版本并发控制

② MVCC多版本并发控制

MVCC全称Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突

MVCC的具体实现，主要依赖于数据库记录中的隐式字段 、undo log日志 、readView。

例如：下面有4个事务，事务2、3、4对该记录都进行了操作，那么在事务5中的两条查询语句是查询的哪个事务版本的记录呢？

MVCC的实现原理：

记录中的隐藏字段
undo log 回滚日志

a. 回滚日志，在insert、 update、 delete的时候产生的便于数据回滚的日志。

b. 当insert 的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除 。

c. 而update、delete 的时候，产生的undo log日志不仅在回滚时需要，mvcc版本访问也需要，不会立即被删除。
undo log 版本链

不同事务或相同事务对同一条记录进行修改，会导致该记录的undo log生成一条记录版本链表，链表的头部是最新的旧记录 ，链表尾部是最早的旧记录 。
readview

ReadView (读视图)是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务(未提交的) id。

a. 当前读 ：读取的是记录的最新版本 ，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如:

select ... lock in share mode(共享锁)，select ... for update、update、 insert、 delete(排他锁)都是一种当前读。

b. 快照读 ：简单的select (不加锁)就是快照读,快照读,读取的是记录数据的可见版本，有可能是历史数据 ，不加锁 ，是非阻塞读。

Read Committed：每次select, 都生成一个快照读。

Repeatable Read：开启事务后第一个select语句才是快照读的地方。