MySQL面试知识复盘（一）

本文主要介绍MySQL的基本语句的用法以及MySQL知识点的一些复盘

一、MySQL连接语句

（一）多表连接语句

• （1）inner join： 只返回两个表中联结字段相等的行。
  

• （2）left join： 以左表为主，先查询出左表，按照ON后的关联条件匹配右表，没有匹配到的用null填充。
  
  

• （3）right join： 以右表为主，先查询出右表，按照ON后的关联条件匹配左表，没有匹配到的用null填充。

• （4）union： 把多个结果集集中在一起，UNION前的结果为基准。

UNION 内部的 SELECT 语句必须拥有相同数量的列。列也必须拥有相似的数据类型。同时，每条 SELECT 语句中的列的顺序必须相同

• （5）union all： 与union相同，但不会合并重复的记录行。
  

（二）基础命令语句

1、查看MySQL提供的所有存储引擎

mysql> show engines;

2、查看MySQL当前默认的存储引擎

mysql> show variables like ‘%storage_engine%’;

3、查看表的存储引擎

mysql> show table status like “table_name” ;

（三）mysql中 in 和 exists 区别

in语句：把外表和内表作hash 连接，
exists语句：是对外表作loop循环，每次loop循环再对内表进行查询。

如果查询的两个表大小相当，那么用in和exists差别不大。
如果两个表中一个较小，一个是大表，则子查询表大的用exists，子查询表小的用in。

not in 和not exists：如果查询语句使用了not in，那么内外表都进行全表扫描，没有用到索引；而not extsts的子查询依然能用到表上的索引。
所以无论那个表大，用not exists都比not in要快。

（四）varchar与char的区别

• char表示定长字符串，长度是固定的；varchar表示可变长字符串，长度是可变的；

• 如果插入数据的长度小于char的固定长度时，则用空格填充；varchar 插入的数据是多长，就按照多长来存储；

• 因为长度固定，所以 char 存取速度要比 varchar 快很多，甚至能快50%，但正因为其长度固定，所以会占据多余的空间，是空间换时间的做法；

• char 最多能存放的字符个数为255，和编码无关；varchar 最多能存放的字符个数为65532

二、MySQL存储引擎相关

1、说说你对MySQL存储引擎的了解？

MySQL的存储引擎主要有 MyISAM 和 InnoDB。

2、MyISAM和InnoDB的区别？

（1）MyISAM 只有表级锁，不支持事务和行级锁；InnoDB 支持行级锁和表级锁，默认为行级锁。

（2）MyISAM 强调的是性能，每次查询具有原子性,其执行速度比InnoDB类型更快，但是不提供事务支持。InnoDB 提供事务支持事务，外部键等高级数据库功能。 具有事务、回滚和崩溃修复能力的事务安全型表。

（3） MyISAM不支持外键，而InnoDB支持外键。

（4）仅 InnoDB 支持MVCC 。应对高并发事务，MVCC比单纯的加锁更高效。

MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作； MVCC可以使用 乐观锁 和 悲观锁来实现；

（5）InnoDB索引是聚簇索引，MyISAM索引是非聚簇索引。InnoDB的主键索引的叶子节点存储着行数据，因此主键索引非常高效。MyISAM索引的叶子节点存储的是行数据地址，需要再寻址一次才能得到数据。

插入知识点：
非聚簇索引：在索引检索的时候，首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其 data 域的值，然后以 data 域的值为地址读取相应的数据记录。
聚簇索引：索引文件和数据文件是分离，其表数据文件本身就是按B+Tree组织的一个索引结构，树的叶节点data域保存了完整的数据记录。

在根据主索引搜索时，直接找到key所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。 因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。

《MySQL高性能》：
不要轻易相信“MyISAM比InnoDB快”之类的经验之谈，这个结论往往不是绝对的。在很多我们已知场景中，InnoDB的速度都可以让MyISAM望尘莫及，尤其是用到了聚簇索引，或者需要访问的数据都可以放入内存的应用。

三、索引相关

（一）什么是索引？

索引是一种特殊的文件，它们包含着对数据表里所有记录的引用指针，占据物理空间。

索引是一种数据结构。数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用B树及其变种B+树。

（二）MySQL索引使用的数据结构有哪些？

MySQL索引使用的数据结构主要有 BTree索引 和 哈希索引 。

对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，可以选择哈希索引，查询性能最快；其余大部分场景，建议选择BTree索引。

（三）索引有哪些优缺点？

优点：

• 可以大大加快数据的检索速度，这也是创建索引的最主要的原因。
• 通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。

缺点：

• 时间方面：创建索引和维护索引要耗费时间，具体地，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，会降低增/改/删的执行效率；
• 空间方面：索引需要占物理空间。

（四）索引有哪些类型？

• 主键索引：数据列不允许重复，不允许为NULL，一个表只能有一个主键。

• 唯一索引：数据列不允许重复，允许为NULL值，一个表允许多个列创建唯一索引。

可以通过 ALTER TABLE table_name ADD UNIQUE (column); 创建唯一索引
可以通过 ALTER TABLE table_name ADD UNIQUE (column1,column2); 创建唯一组合索引

• 普通索引：基本的索引类型，没有唯一性的限制，允许为NULL值。

可以通过ALTER TABLE table_name ADD INDEX index_name (column); 创建普通索引
可以通过ALTER TABLE table_name ADD INDEX index_name(column1, column2, column3); 创建组合索引

• 全文索引： 是目前搜索引擎使用的一种关键技术。

可以通过ALTER TABLE table_name ADD FULLTEXT (column); 创建全文索引

（五）索引的创建原则？

• 最左前缀匹配原则。
• 较频繁作为查询条件的字段才去创建索引
• 更新频繁字段不适合创建索引
• 若是不能有效区分数据的列不适合做索引列
• 尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。
• 定义有外键的数据列一定要建立索引。
• 对于那些查询中很少涉及的列，重复值比较多的列不要建立索引。
• 对于定义为text、image和bit的数据类型的列不要建立索引。

（六）索引的创建、删除语句

创建：

--第一种：在执行CREATE TABLE时创建索引
CREATE TABLE user_index (
	id INT auto_increment PRIMARY KEY,
	name VARCHAR (16),
	id_card VARCHAR (18),
	UNIQUE KEY (id_card)
);

--第二种：使用ALTER TABLE命令去增加索引
ALTER TABLE table_name ADD INDEX index_name (column_list);

--第三种：使用CREATE INDEX命令创建
CREATE INDEX index_name ON table_name (column_list);

删除：

alter table table_name drop KEY index_name;

--如果主键自增长，不能直接删除（自增长依赖于主键索引），需要取消自增长再行删除：
alter table user_index
-- 重新定义字段
MODIFY id int,
drop PRIMARY KEY

（七）百万级别或以上的数据如何删除？

（1）先删除索引（此时大概耗时三分多钟）

（2）然后删除其中无用数据（此过程需要不到两分钟）

（3）删除完成后重新创建索引(此时数据较少了)创建索引也非常快，约十分钟左右。

（八）非聚簇索引一定会回表查询吗？

不一定，这涉及到查询语句所要求的字段是否全部命中了索引，如果全部命中了索引，那么就不必再进行回表查询。

（九）索引的使用场景？

（1）where

（2）order by
使用order by将查询结果按照某个字段排序时，如果该字段没有建立索引，那么执行计划会将查询出的所有数据使用外部排序（将数据从硬盘分批读取到内存使用内部排序，最后合并排序结果），这个操作很影响性能，因为需要将查询涉及到的所有数据从磁盘中读到内存（如果单条数据过大或者数据量过多都会降低效率），更无论读到内存之后的排序了。

如果对该字段建立索引alter table 表名 add index(字段名)，那么由于索引本身是有序的，因此直接按照索引的顺序和映射关系逐条取出数据即可。而且如果分页的，那么只用取出索引表某个范围内的索引对应的数据，而不用像上述那取出所有数据进行排序再返回某个范围内的数据。（从磁盘取数据是最影响性能的）

（3）join：
对join语句匹配关系（on）涉及的字段建立索引能够提高效率

四、事务相关

（一）什么是事务？

事务是逻辑上的一组操作，要么都执行，要么都不执行，是数据库并发控制的基本单位。

（二）事务的特性？

• 原子性（Atomicity）： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
• 一致性（Consistency）： 执行事务前后，数据保持一致，多个事务对同一个数据读取的结果是相同的；
• 隔离性（Isolation）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
• 持久性（Durability）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

（三）并发事务带来的问题？

• 脏读（Dirty read）： 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。
• 丢失修改（Lost to modify）： 指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。
• 不可重复读（Unrepeatableread）： 指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。
• 幻读（Phantom read）： 幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

不可重复读和幻读区别：
不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改，幻读的重点在于新增或者删除比如多次读取一条记录发现记录增多或减少了。

（四）事务隔离级别有哪些？MySQL的默认隔离级别是？

SQL 标准定义了四个隔离级别：

• READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
• READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
• REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
• SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读），虽然支持的是RR级别，但是不会出现幻读问题，因为采用了next-key lock锁算法防止了幻读产生。

五、锁相关

（一）对MySQL锁了解吗？

当数据库有并发事务的时候，可能会产生数据的不一致，这时候需要一些机制来保证访问的次序，锁机制就是这样的一个机制。

（二）锁机制

在关系型数据库中，可以按照锁的粒度把数据库锁分为行级锁、表级锁和页级锁。

• 表级锁： MySQL中锁定粒度最大的一种锁，对当前操作的整张表加锁，实现简单，资源消耗也比较少，加锁快，不会出现死锁。其锁定粒度最大，触发锁冲突的概率最高，并发度最低，MyISAM和 InnoDB引擎都支持表级锁。
• 行级锁： MySQL中锁定 粒度最小 的一种锁，只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会出现死锁。
• 页级锁： 页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。

MyISAM采用表级锁；InnoDB支持行级锁和表级锁，默认为行级锁

在Read Uncommitted级别下，读取数据不需要加共享锁，这样就不会跟被修改的数据上的排他锁冲突；
在Read Committed级别下，读操作需要加共享锁，但是在语句执行完以后释放共享锁；
在Repeatable Read级别下，读操作需要加共享锁，但是在事务提交之前并不释放共享锁，也就是必须等待事务执行完毕以后才释放共享锁；
SERIALIZABLE 是限制性最强的隔离级别，因为该级别锁定整个范围的键，并一直持有锁，直到事务完成。

插个知识点：
共享锁（S锁）： 又被称为读锁，其他用户可以并发读取数据，但任何事务都不能获取数据上的排他锁，直到已释放所有共享锁。如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获取共享锁的事务只能读数据，不能修改数据。
排他锁（X锁）： 又称为写锁，若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。它防止任何其它事务获取资源上的锁，直到在事务的末尾将资源上的原始锁释放为止。在更新操作(INSERT、UPDATE 或 DELETE)过程中始终应用排它锁。获取排他锁的事务既能读数据，又能修改数据。

（三）InnoDB锁算法

InnoDB存储引擎的锁的算法有三种：

• Record lock：单个行记录上的锁
• Gap lock：间隙锁，锁定一个范围，不包括记录本身
• Next-key lock：record+gap 锁定一个范围，包含记录本身

• Innodb对于行的查询使用next-key lock
• Next-locking keying为了解决Phantom Problem幻读问题
• 当查询的索引含有唯一属性时，将next-key lock降级为record key
• Gap锁设计的目的是为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生
• 有两种方式显式关闭gap锁：A. 将事务隔离级别设置为RC
  B. 将参数innodb_locks_unsafe_for_binlog设置为1

（四）从锁的类别上分MySQL都有哪些锁呢？像上面那样子进行锁定岂不是有点阻碍并发效率了？

从锁的类别上来讲，有共享锁和排他锁。

• 共享锁: 又叫做读锁。 当用户要进行数据的读取时，对数据加上共享锁。共享锁可以同时加上多个。
• 排他锁: 又叫做写锁。 当用户要进行数据的写入时，对数据加上排他锁。排他锁只可以加一个，他和其他的排他锁，共享锁都相斥。

（五）MySQL中InnoDB引擎的行锁是怎么实现的？

InnoDB是基于索引来完成行锁

例: select * from tab_with_index where id = 1 for update;

for update 可以根据条件来完成行锁锁定，并且 id 是有索引键的列，如果 id 不是索引键那么InnoDB将完成表锁，并发将无从谈起

（六）什么是死锁？怎么解决？

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象。

常见的解决死锁的方法：

• 如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。
• 在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；
• 对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；
• 如果业务处理不好可以用分布式事务锁或者使用乐观锁

（七）数据库的乐观锁和悲观锁是什么？怎么实现的？

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。在查询完数据的时候就把事务锁起来，直到提交事务。实现方式：使用数据库中的锁机制

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。在修改数据的时候把事务锁起来，通过version的方式来进行锁定。
实现方式：乐观锁一般会使用版本号机制或CAS算法实现。

两种锁的使用场景：
乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。

悲观锁适用于写比较多的情况下（多写场景），多写的情况下一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能。

六、MySQL优化方面

（一）如何定位及优化SQL语句的性能问题？如何发现创建的索引有没有被使用到？

MySQL提供了explain命令来查看语句的执行计划

type关键字： 访问类型

• ALL 扫描全表数据
• index 遍历索引
• range 索引范围查找
• index_subquery 在子查询中使用 ref
• unique_subquery 在子查询中使用 eq_ref
• ref_or_null 对Null进行索引的优化的 ref
• fulltext 使用全文索引
• ref 使用非唯一索引查找数据
• eq_ref 在join查询中使用PRIMARY KEYorUNIQUE NOT NULL索引关联。

possible_keys关键字： 可能使用的索引，注意不一定会使用。
查询涉及到的字段上若存在索引，则该索引将被列出来。当该列为 NULL时就要考虑当前的SQL是否需要优化了。

key关键字： 显示MySQL在查询中实际使用的索引，若没有使用索引，显示为NULL。

ref关键字： 表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值

extra关键字：

• Using index 使用覆盖索引
• Using where 使用了用where子句来过滤结果集
• Using filesort 使用文件排序，使用非索引列进行排序时出现，非常消耗性能，尽量优化
• Using temporary 使用了临时表 sql优化的目标

（二）SQL的生命周期？

（1）应用服务器与数据库服务器建立一个连接

（2）数据库进程拿到请求sql

（3）解析并生成执行计划，执行

（4）读取数据到内存并进行逻辑处理

（5）通过步骤一的连接，发送结果到客户端

（6）关掉连接，释放资源

（三）如何优化大表？

• 优化shema、sql语句+索引；
• 限定数据的范围：务必禁止不带任何限制数据范围条件的查询语句；
• 加缓存，memcached, redis；
• 主从复制，读写分离；
• 垂直拆分：根据数据库里面数据表的相关性进行拆分，简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表
  

垂直拆分的优点： 可以使得列数据变小，在查询时减少读取的Block数，减少I/O次数。此外，垂直分区可以简化表的结构，易于维护。
垂直拆分的缺点： 主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决。
此外，垂直分区会让事务变得更加复杂；

• 水平切分：保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中，达到了分布式的目的。 水平拆分可以支撑非常大的数据量。
  

分表仅仅是解决了单一表数据过大的问题，但由于表的数据还是在同一台机器上，其实对于提升MySQL并发能力没有什么意义，所以水平拆分最好分库 。

水平拆分能够支持非常大的数据量存储，应用端改造也少，但分片事务难以解决 ，跨节点Join性能较差，逻辑复杂，尽量不要对数据进行分片，因为拆分会带来逻辑、部署、运维的各种复杂度

补充一下数据库分片的两种常见方案：

• 客户端代理： 分片逻辑在应用端，封装在jar包中，通过修改或者封装JDBC层来实现。 当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。
• 中间件代理： 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。

（四）关心过业务系统里面的sql耗时吗？统计过慢查询吗？对慢查询都怎么优化过？

在业务系统中，除了使用主键进行的查询，其他的我都会在测试库上测试其耗时，慢查询的统计主要由运维在做，会定期将业务中的慢查询反馈给我们。

慢查询的优化首先要搞明白慢的原因是什么？ 是查询条件没有命中索引？是load了不需要的数据列？还是数据量太大？

所以优化也是针对这三个方向来的：

• 首先分析语句，看看是否load了额外的数据，可能是查询了多余的行并且抛弃掉了，可能是加载了许多结果中并不需要的列，对语句进行分析以及重写。
• 分析语句的执行计划，然后获得其使用索引的情况，之后修改语句或者修改索引，使得语句可以尽可能的命中索引。
• 如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果是的话可以进行横向或者纵向的分表。

（五）主键为什么不建议使用UUID？

因为在InnoDB存储引擎中，主键索引是作为聚簇索引存在的，也就是说，主键索引的B+树叶子节点上存储了主键索引以及全部的数据，如果用UUID，由于到来的ID与原来的大小不确定，会造成非常多的数据插入，数据移动，然后导致产生很多的内存碎片，进而造成插入性能的下降。

关于主键是聚簇索引，如果没有主键，InnoDB会选择一个唯一键来作为聚簇索引，如果没有唯一键，会生成一个隐式的主键。

（六）MySQL数据库cpu突然飙升到500%的话怎么处理？

当 cpu 飙升到 500%时，先用操作系统命令 top 命令观察是不是 mysqld 占用导致的，如果不是，找出占用高的进程，并进行相关处理。

如果是 mysqld 造成的， show processlist，看看里面跑的 session 情况，是不是有消耗资源的 sql 在运行。找出消耗高的 sql，看看执行计划是否准确， index 是否缺失，或者实在是数据量太大造成。

一般来说，肯定要 kill 掉这些线程(同时观察 cpu 使用率是否下降)，等进行相应的调整，比如说加索引、改 sql、改内存参数，再重新跑这些 SQL。

也有可能是每个 sql 消耗资源并不多，但是突然之间，有大量的 session 连进来导致 cpu 飙升，这种情况就需要跟应用一起来分析为何连接数会激增，再做出相应的调整，比如说限制连接数等

（七）如何优化LIMIT分页？

• LIMIT偏移量大的时候，查询效率较低
• 可以记录上次查询的最大ID，下次查询时直接根据该ID来查询

（八）MySQL的复制原理以及流程

主从复制：将主数据库中的DDL和DML操作通过二进制日志（BINLOG）传输到从数据库上，然后将这些日志重新执行（重做）；从而使得从数据库的数据与主数据库保持一致。

（1）MySQL主从复制工作原理：

• 在主库上把数据更高记录到二进制日志
• 从库将主库的日志复制到自己的中继日志
• 从库读取中继日志的事件，将其重放到从库数据中

主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中；

从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进自己的relay log中；

从：sql执行线程——执行relay log中的语句；

（2）复制过程：

Binary log：主数据库的二进制日志
Relay log：从服务器的中继日志

• 第一步：master在每个事务更新数据完成之前，将该操作记录串行地写入到binlog文件中。

• 第二步：salve开启一个I/O Thread，该线程在master打开一个普通连接，主要工作是binlog dump process。如果读取的进度已经跟上了master，就进入睡眠状态并等待master产生新的事件。I/O线程最终的目的是将这些事件写入到中继日志中。

• 第三步：SQL Thread会读取中继日志，并顺序执行该日志中的SQL事件，从而与主数据库中的数据保持一致。

（3）主从复制的作用：

• 数据分布：随意开始或停止复制，并在不同地理位置分布数据备份
• 负载均衡：降低单个服务器的压力
• 高可用和故障切换：帮助应用程序避免单点失败
• 升级测试：可以用更高版本的MySQL作为从库

（九）SQL语句优化的一些方法：

（1）对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引；

（2）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描；

（3）应尽量避免在 where 子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描；

（4）应尽量避免在 where 子句中使用or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描；

（5）in 和 not in 也要慎用，否则会导致全表扫描，对于连续的数值，能用 between 就不要用 in 了；

（6）如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项；

（7）应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描；

（8）应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描；

（9）不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

本文参考文章：
MySQL数据库面试题（2020最新版）
JavaGuide面试突击版