16. MySQL数据引擎：

引擎分类：

show engines命令查看数据库支持的存储引擎。

描述一下InnoDB和MyISAM的区别？**

• InnoDB存储限制64TB，而MyISAM存储限制256TB；
• InnoDB支持事物，而MyISAM不支持；
• InnoDB支持外键，而MyISAM不支持；
• InnoDB支持行级锁（默认）+表级锁，而MyISAM支持表级锁；
• InnoDB支持MVCC（多版本并发控制技术）, 而MyISAM不支持；
• InnoDB即支持聚簇索引又支持非聚簇索引，而MyISAM 只支持非聚簇索引；
• InnoDB不支持全文索引（5.6版本之后支持），而MyISAM支持。

如何选择？

现在MySQL的默认存储引擎已经变成了InnoDB，推荐使用InnoDB：

• 1. 是否需要支持事务，如果需要选择InnoDB，如果不需要选择MyISAM；
• 2. 如果表的大部分请求都是读请求，可以考虑MyISAM，如果既有读也有写，使用InnoDB。

17. 描述一下MySQL主从复制的机制的原理？MySQL主从复制主要有几种模式？（没啥印象）

原理：

• 从库会生成两个线程：I/O线程和SQL线程；
  • I/O线程会去请求主库的binlog，并将得到的binlog写到本地的relay log(中继日志)文件中；
  • SQL线程会读取relay log文件中的日志，并解析成SQL语句，并逐一执行。
• 同步时，主库会生成一个dump线程，用来给从库I/O线程传binlog。

模式：

一主一从、主主复制、一主多从、多主一从、联级复制。

主从同步延迟问题：*

• 原因：
  • DML和DDL的IO操作是随机的，不是顺序，成本很高；
  • 主库在高并发时，从库的SQL线程处理不过来；
  • Slave中有大型Query语句产生了锁等待。
• 解决：
  • 提高机器性能；
  • 业务分库，一主多从；
  • 加缓存层。

18. 如何优化SQL，查询计划（Explain）的结果中看哪些些关键数据？

前提：**

• 做好表结构设计，相关字段提前加索引。
• 业务处理，减少数据库连接；增加缓存层等。

如何优化：

• 开启慢查询日志（不说，因为没有实战经验）。
• 查询的优化：
  • 减少连接次数；
  • 返回更少的数据；
  • 加索引，并且避免全表扫描，注意查看索引是否生效，是否效率高。
• 合理的分库分表。
• 数据库访问优化（建立数据库连接池，建索引）。

Explain作用：

模拟MySQL优化器运行SQL语句，了解MySQL如何处理你的SQL语句。分析SQL查询语句或是表结构的性能瓶颈。

Explain解释：

• id列（数据列的执行顺序）
• select_type列（数据读取操作的操作类型）
• table列（该行数据是关于哪张表）
• type列（访问类型，重点关注）：
  • 由好到差system > const > eq_ref > ref > range > index > ALL，一般来说，保证查询至少达到range级别，最好能达到ref。
  • system：表只有一条记录(等于系统表)，这是const类型的特例，平时业务中不会出现。
  • const：通过索引一次查到数据，该类型主要用于比较primary key 或者unique 索引，因为只匹配一行数据，所以很快。
  • eq_ref：唯一索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或者唯一索引扫描。
  • ref：非唯一索引扫描，返回匹配某个单独值得所有行，本质上是一种索引访问，它返回所有匹配某个单独值的行。
  • range：只检索给定范围的行，使用一个索引来选着行。key列显示使用了哪个索引。一般在你的WHERE 语句中出现between 、< 、> 、in 等查询，这种给定范围扫描比全表扫描要好。因为他只需要开始于索引的某一点，而结束于另一点，不用扫描全部索引。
  • index：FUll Index Scan 扫描遍历索引树(扫描全表的索引，从索引中获取数据)。
  • ALL：全表扫描 从磁盘中获取数据 百万级别的数据ALL类型的数据尽量优化。
• possible_keys列（显示可能应用在这张表的索引）
• keys列（实际使用到的索引，重点关注）
• ken_len列（索引中使用的字节数，重点关注）
• ref列（显示索引的哪一列被使用）
• rows列（每张表有多少行被优化器查询，重点关注）
• Extra列（扩展属性）:Using filesort 、Using temporary 、 Using index ....
  • using filesort：排序的字段没有使用索引
  • Using temporary : 使用了临时表保存中间结果

https://www.cnblogs.com/gdwkong/articles/8505125.html

19. 描述一下MySQL的乐观锁和悲观锁，锁的种类？

乐观锁：

乐观锁并不是数据库自带的，需要自己去实现，一般情况下，我们会在表中新增一个version字段，每次更新数据version+1，在进行提交之前会判断version是否一致。

悲观锁：

MySQL中的绝大部分锁都是悲观锁，按照粒度可以分为行锁和表锁：

• 行锁：***
  • 共享锁：当读取一行记录的时候，为了防止别人修改，则需要添加S锁。
  • 排它锁：当修改一行记录的时候，为了防止别人同时进行修改，则需要添加X锁。

• • 记录锁（Record Lock）：添加在行索引上的锁。
  • 间隙锁（Gap Lock）：它的锁定范围是索引记录之间的间隙，针对可重复读以上隔离级别。
  • 临键锁（Next-key Lock）：记录锁 + 间隙锁。
• Tips：
  • 如果不需要解决幻读问题，不要加临键锁和间隙锁。
  • 加锁方式：SELECT ... for update；

• 表锁：
  • 意向锁：在获取某行的锁之前，必须要获取表的锁，分为意向共享锁（IS），意向排它锁（IX）。
  • 自增锁：对自增字段所采用的特殊表级锁。

锁的应用：

事务的隔离级别。

MySQL加锁情况分析：***

《见MySQL加锁》

锁模式（lock_mode）的含义： -> show engine innodb status\G; 查看

• IX：意向排它锁
• IS：意向共享锁
• X：锁定记录本身和记录之前的间隙，即临键锁
• S：锁定记录本身和记录之前的间隙，即临键锁
• X，REC_NOT_GAP：只锁定记录本身，即记录锁
• S，REC_NOT_GAP：只锁定记录本身，即记录锁
• X，GAP：间隙锁，不锁定记录本身
• S，GAP：间隙锁，不锁定记录本身
• X，GAP，INSERT_INTENTION：插入意向锁

20. MySQL数据库在什么情况下出现死锁？产生死锁的四个必要条件？如何解决死锁？

概念：

两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。

产生死锁的四个必要条件：

• 互斥条件：任何时刻一个资源只能被一个进程使用，其他进程只能等待。
• 请求和保持条件：进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己获得的其它资源保持不放。
• 不剥夺条件：进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
• 环路等待条件：A想占有B在等待的资源（B等待A释放），B想占有A在等待的资源（A等待B释放）形成环路。

如何解决死锁？

• （1）顺序加锁、顺序访问表，可以大大降低死锁机会。
• （2）容易产生死锁的业务，可以升级锁的颗粒度（表级锁），减少死锁产生的概率。
• （3）设置超时时间，若事务超时就回滚，另一个等待的事务就能得以继续执行。