MySQL常见面试题

MySQL

优化

定位慢查询
SQL执行计划：SQL分析能力
SQL优化经验：SQL优化
索引
- 存储引擎
- 索引底层数据结构
- 聚簇和非聚簇索引
- 索引创建原则
- 索引失效场景

其他

事务相关：事务特性隔离级别 MVVC
主从同步原理：高并发
分库分表：海量数据存储

一.索引

1.什么是索引?

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

在数据之外,数据库系统还维护着满足特定查找算法的数据结构(B+树 ),这些数据结构以某种方式指向数据,这样就可以在这些数据结构上实现高级查找算法.

2.索引创建的原则

先陈述自己在工作中是如何运用的
主键索引
唯一索引
根据业务创建索引(复合索引)

1.针对数据量比较大,且查询比较频繁的表建立索引

单表如果超过10w数据 (增加用户体验)

目的就是查询表的时候速度更快

2.针对常作为 查询条件的 where order by 分组group by 操作的字段建立索引
3.尽量去选择区分度高的列作为索引,尽量建立唯一索引,区分度越高,使用索引的效率越高

这里的区分度就不高,所以尽量不使用这种字段作为索引

4.如果是字符串,字段的长度较长,可以针对于字段的特点,建立前缀索引

5.尽量使用联合索引,减少单列索引 ,查询时,联合索引很多时候可以覆盖索引(避免回表),节省存储空间,提高查询效率

6.需要控制索引的数量,索引并不是多多益善,索引越多,维护成本就越大 ,从而会影响增删改的效率
7.如果**索引列不能存储null值,请在创建表时使用NOT NULL 去约束它,**当优化器知道每列是否包含NULL值时,可以更好的确定哪个索引最有效地用于查询.

总结:

数据量大且查询比较频繁的表
常作为查询条件的字段
字段内容区分度比较高
内容比较长 使用前缀索引
尽量联合索引
要控制索引的数量
如果索引不能存储null值,在创建表时使用NOT NULL去约束它

3索引的底层数据结构是什么?

B+树

MySQL的InnoDB引擎采用的是B+树的数据结构来存储索引

阶树更多,路径更短
磁盘读写代价B+树更低, 非叶子结点只存储指针,叶子结点存储数据
B+树 便于扫库和区间查询 ,叶子结点是一个 双向链表

数据结构对比

B树是一种多叉路衡查找树,相当于二叉树,B树每个节点可以有多个分支,多叉.

4.B+树:

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

区别在于

非叶子结点只存储指针不存储数据

叶子结点才会真正的去存储数据

磁盘读写代价B+树更低
查询效率B+树更加稳定
B+树便于扫库和区间查询

结点直接存在双向指针,相当于查询6 他可以一次性把所有的数据都拿到

总结:

索引是帮助MySQL高效获取数据的数据结构
是为了提高数据检索的效率,降低数据库的IO成本(不需要全表扫描)
通过索引对数据进行排序,降低数据排序的成本,降低了CPU的消耗

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

什么是聚集索引,什么是二级索引(非聚簇索引)

什么是回表?

聚餐索引

将 数据存储 与索引放到一块,索引结构的叶子节点保存了行数据 ,必须有,而且只有一个

二级索引

将数据与索引分开存储,索引结构的叶子节点关联的对应的主键 , 可以存在多个

聚簇索引选取规则:

如果存在主键,主键索引就是聚集索引
如果不存在主键,将使用唯一 UNIQUE 索引作为聚集索引
如果表没有主键,或者没有合适的唯一索引,InnoDB会自动生成一个rowid作为隐藏的聚集索引

回表查询

先通过二级索引找到对应的主键值,拿到主键再到聚集索引中查询出整行的数据,这个过程叫做回表查询

总结:

聚集索引(聚簇索引):数据与索引放到一块,B+树的叶子节点保存的整行的数据,有且只有一个
二级索引:数据与索引分开存储,B＋树的叶子结点上存储的是对应的主键,可以有多个
什么是回表查询?
- 通过二级索引找到对应的主键值,然后再到聚簇索引中查询出整行的数据,这个过程就是回表查询

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

7.如何去快速判断索引是否失效呢

执行计划explain

name status address

违法了最左前缀法则

失效的情况:

范围查询右边的列不能使用索引

不要在索引列上进行运算操作,索引将失效

这里使用的substring进行了运算操作,且在索引列上

字符串不加单引号,造成索引失效

查询的时候,没有对字符串加单引号,MySQL 查询优化器,会自动的进行类型转换, 造成索引失效

模糊查询有可能会导致索引失效

总结:

违反了最左前缀法则: 使用复合索引,不能跳过某一列去查询
范围查询右边的列,不能使用索引
不要在索引上进行运算操作,索引会失效
字符串不加单引号,造成索引失效(类型转换)
以百分号% 开头的Like模糊查询,索引失效

二.MySQL中，如何定位慢查询

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

表象：页面加载过慢、接口压测响应时间过长

方案一：开源工具

调试工具：Arthas
运维工具：Skywalking Prometheus

方案二：MySQL自带慢日志查询

执行慢的SQL执行在日志文件中

默认MySQL没有开启我们只需要在配置文件中开启就行

/etc/my.cnf

SQL 复制代码

# 开启MySQL慢日志查询开关
slow_query_log=1
# 设置慢查询的时间为2s SQL语句执行时间超过2s
long_query_time=2
# 配置完毕之后，通过指令重启MySQL服务器进行测试，查看慢日志文件中的记录
/var/lib/mysql/localhost-slow.log

总结：

介绍当时问题问题产生的场景
我们系统中采用了skywalking 可以检测出哪个接口，最终原因是sql的问题
在mysql中开启慢查询日志，一旦sql查询超过2s就会记录到日志中

三.sql语句执行的很慢，如何分析

SQL语句执行的很慢如何去分析呢？

聚合查询
多表查询
表数据量过大查询： 添加索引
深度分页查询

前三个可以通过 SQL执行计划找到慢的原因

EXPLAIN DESC命令获取到MySQL如何执行SELECT 语句信息

直接在select语句之前加上 explain/desc

这些字段不需要全部掌握

possible_key :当前sql可能会使用到的索引
key 当前sql 实际命中的索引
key_len 索引占有的大小
Extra 额外的优化建议

通过查看是否命中索引就是看 key 和key_len

出现了Using index condition 说明索引的使用是有优化的空间的

type sql连接的类型 null system const eq_ref ref range index all

越往左边性能越好

system :查询系统中的表

const:根据主键查询

eq_ref:主键索引查询或者唯一索引查询

ref:索引查询

range :范围查询

index:索引树扫描

all:全盘扫描

总结:

如果 SQL执行很慢,如何分析

我们可以采用MySQL自带的分析工具Explain
通过查看key 和key_len检查是否命中了索引 (索引本身存在是否失效的问题)
通过查看 type字段查看sql是否有进一步的优化空间,是否存在全索引扫描或者全盘扫描
通过extra建议来判断,是否出现了回表的情况,如果出现了可以添加索引或者修改返回字段来修复

四.谈谈SQL优化经验

表的设计优化
索引优化： 参考优化创建原则和索引失效的原则
SQL语句优化
主从复制、读写分离
分库分表 后面专门章节介绍

1.表设计的优化

参考阿里开发手册嵩山版本

2.SQL语句优化

避免使用select* 有可能会造成回表查询
SQL语句要避免索引失效的写法
尽量使用 union all 代替 union， union会多一次过滤，效率低
避免在where子句中对字段进行表达式操作，例如substring 索引失效的时候讲到过在索引字段上进行表达式操作
Join 优化能用 inner join 就不用 left join right join，如果必须使用一定要以小表驱动，内连接会对两个表进行优化，优先把小表放到外边，把大表放到里面。 left join 或 right join ，不会重新调整顺序