1.如何定位慢查询?

        1.1.介绍一下当时产生问题的场景(我们当时的接口测试的时候非常的慢，压测的结果大概5秒钟))，可以监测出哪个接口，最终因为是sql的问题

         1.2.我们系统中当时采用了运维工具(Skywalkin就是2秒，一旦sql执行超过2秒就会记录到日志中(调试阶段)

        1.3.在mysql中开启了慢日志查询，我们设置的值就是2秒，一旦sql执行超过2秒就会记录到日志中(调试阶段)

2. 这个SQL语句执行很慢,如何分析呢?

可以采用MySQL自带的分析工具 EXPLAIN
        2.1通过key和key len检查是否命中了索引(索引本身存在是否有失效的情况)

        2.2通过type字段查看sql是否有进一步的优化空间，是否存在全索引扫描或全盘扫描

        2.3通过extra建议判断，是否出现了回表的情况，如果出现了，可以尝试添加索引或修改返回字段来修复

3.(什么是索引)了解过索引吗?

        索引(index)是帮助MySQL高效获取数据的数据结构(有序)

        它提高数据检索的效率，降低数据库的IO成本(不需要全表扫描)

        通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗

4.索引的底层数据结构了解过嘛 ?

        MySQL的InnoDB引擎采用的B+树的数据结构来存储索引
        阶数更多，路径更短
        磁盘读写代价B+树更低，非叶子节点只存储指针，叶子阶段存储数据B+树便于扫库和区间查询，叶子节点是一个双向链表

5.什么是聚簇索引什么是非聚簇索引?

        聚簇索引(聚集索引):数据与索引放到一块，B+树的叶子节点保存了整行数据，有且只有一个

        非聚簇索引(二级索引):数据与索引分开存储，B+树的叶子节点保存对应的主键，可以有多个

6.知道什么是回表查询嘛 ?

        通过二级索引找到对应的主键值，到聚集索引中查找整行数据，这个过程就是回表

7.知道什么叫覆盖索引嘛 ?

        覆盖索引是指查询使用了索引，返回的列，必须在索引中全部能够找到

        7.1 使用id查询，直接走聚集索引查询，一次索引扫描，直接返回数据，性能高。

       7.2  如果返回的列中没有创建索引，有可能会触发回表查询，尽量避免使用select*

8.MYSQL超大分页怎么处理?

        问题:在数据量比较大时，limit分页查询，需要对数据进行排序，效率低

        解决方案:覆盖索引+子查询

9.索引创建原则有哪些?

        1).数据量较大，且查询比较频繁的表

        2).常作为查询条件、排序、分组的字段

        3).字段内容区分度高

        4).内容较长，使用前缀索引

        5).尽量联合索引

        6).要控制索引的数量

        7).如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它

10.什么情况下索引会失效 ?

        违反最左前缀法则
        范围查询右边的列，不能使用索引
        不要在索引列上进行运算操作，索引将失效字符串不加单引号，造成索引失效。(类型转换)
        以%开头的Like模糊查询，索引失效

11.谈谈你对sql的优化的经验

       11.1 表的设计优化(参考阿里开发手册《嵩山版》)
                ① 比如设置合适的数值(tinyint int bigint)，要根据实际情况选择
                ② 比如设置合适的字符串类型(char和varchar)char定长效率高，varchar可变长度，效率稍低

       11.2 SQL语句优化
                SELECT语句务必指明字段名称(避免直接使用select*)

                SQL语句要避免造成索引失效的写法

                尽量用union all代替union union会多一次过滤，效率低

                避免在where子句中对字段进行表达式操作

                Join优化 能用innerjoin 就不用left join right join，如必须使用 一定要以小表为驱动内连接会对两个表进行优化，优先把小表放到外边，把大表放到里边。leftjoin 或 right join，不会重新调整顺序

       11.3·主从复制、读写分离
                如果数据库的使用场景读的操作比较多的时候，为了避免写的操作所造成的性能影响 可以采用读写分离的架构。读写分离解决的是，数据库的写入，影响了查询的效率.

        11.4. 索引优化，索引创建原则

        11.5 分库分表

12. 事务是什么

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

13.事务的ACID是什么?可以详细说一下吗?

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

14.并发事务的问题有什么？

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

15.事务的隔离级别有哪些？

Read uncommitted 读未提交:三种并发事务都不能解决
Read committed 读已提交：能解决脏读
Repeatable Read(默认) 可重复读（mysql的默认隔离级别）：能解决脏读和不可重复读
Serializable 串行化：三种并发事务都能解决

16.redo log

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

该日志文件由两部分组成:重做日志缓冲(redologbuffer)以及重做日志文件(redolog file),前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都存到该日志文件中,用于在刷新脏页到磁盘,发生错误时,进行数据恢复使用。

17. undo log

回滚日志，用于记录数据被修改前的信息,作用包含两个:提供回滚 和 MVCC(多版本并发控制)。undolog和redo loq记录物理日志不一样，它是逻辑日志
可以认为当delete一条记录时，undolog中会记条对应的insert记录，反之亦然
当update一条记录时，它记录一条对应相反的upate记录。当执行rolback时，就可以从undolog中的逻辑记录读取到相应的内容并进行回滚。undolog可以实现事务的一致性和原子性

18.undo log和redo log的区别

redo log:记录的是数据页的物理变化，服务宕机可用来同步数据

undo log:记录的是逻辑日志，当事务回滚时，通过逆操作恢复原来的数据

redo log保证了事务的持久性，undolog保证了事务的原子性和一致性

19.解释-下MVCC

全称 Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突， MVCC的具体实现，主要依赖于数据库记录中的隐式字段、undolog日志、readView。

20.好的，事务中的隔离性是如何保证的呢?(你解释一下MVCC)

MySQL中的多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突
20.1隐藏字段:
① trx id(事务id)，记录每一次操作的事务id，是自增的
② roll pointer(回滚指针)，指向上一个版本的事务版本记录地址

20.2 undo log:
① 回滚日志，存储老版本数据
② 版本链:多个事务并行操作某一行记录，记录不同事务修改数据的版本，通过roll_pointer指针形成一个链表

20.3 readView解决的是一个事务查询选择版本的问题
根据readView的匹配规则和当前的一些事务id判断该访问那个版本的数据
不同的隔离级别快照读是不一样的，最终的访问的结果不一样

RC:每一次执行快照读时生成ReadView
RR:仅在事务中第一次执行快照读时生成ReadView，后续复用

21.mysql主从同步原理 

MySQL主从复制的核心就是二进制日志binlog(DDL(数据定义语言)语句和 DML(数据操纵语言)语句)

① 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。
② 从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。
③ 从库重做中继日志中的事件，将改变反映它自己的数据

22.你们项目用过分库分表吗

业务介绍
1，根据自己简历上的项目，想一个数据量较大业务(请求数多或业务累积大)
2，达到了什么样的量级(单表1000万或超过20G)
具体拆分策略
1，水平分库，将一个库的数据拆分到多个库中，解决海量数据存储和高并发的问题(sharding-                       sphere、mycat)
2，水平分表，解决单表存储和性能的问题(sharding-sphere、mycat)
3，垂直分库，根据业务进行拆分，高并发下提高磁盘10和网络连接数
4，垂直分表，冷热数据分离，多表互不影响