微信公众号原文链接，排版更舒服

作为一名大公司的后端应届生，深知一路上无人指导的艰辛，也想把自己的心路历程和经历分享给大家。 后续各大厂商专访系列将持续更新……

原创图文八篇论文面试网站，更多优质专栏及大公司面试必答题解析请前往：

地址： //

在线阅读网站：上一篇文章

众所周知，如果你想进大厂，MYSQL是你必须要问的技术之一。 如果你在中小型公司工作，也许简单的CRUD对于数据库操作就足够了。 然而对于大型厂商来说，面对百万级的数据量，如何才能保证MYSQL的性能仍然很好呢？

这其实涉及到很多方面：索引、主从读写分离、集群、分库分表、SQL、锁、参数调优、表结构等等。本文想带领大家讨论一下“可能的情况”。 SQL语句执行速度很慢的原因以及如何优化？”。

由于作者水平有限，考虑的可能不是很全面。 欢迎留言补充。

关注我的朋友应该都知道我的原则：如果你想了解更多或者想知道具体的内部实现建议，请仔细阅读本书。 这里我简单分享一下我的理解。 知道了这些，面试基本就够了。

（悄悄话：我也是看书+偷学阿里面试官的东西！）

sql怎么会变慢呢？

我从来不喜欢说废话，也不喜欢做广告，网上同样的文章讲了半天也抓不到重点。 只适合大公司面试。 接下来看我如何回答。 干货慢慢来了。 如有不足之处，请留言并指正。

我认为 SQL 执行速度非常慢。 我们需要分两种情况来讨论：

1.大多数情况下是正常的，但偶尔会很慢。 原因如下：

(1)数据库正在刷新脏页。 例如，重做日志已满，需要同步到磁盘。

(2)执行过程中遇到锁，比如表锁、行锁。

(3)、sql写的不好

2. 该SQL语句执行速度非常慢，原因如下：

(1)索引没有使用或者索引无效：例如字段没有索引； 或者由于对字段的操作或函数操作导致索引无法使用。

(2)如果有索引，可能会进行全表扫描。

如何判断是否进行全表扫描：

指标歧视性（指标值差异越多，歧视性越高）称为基数。 当数据量很大时，不可能扫描所有数据来得到基数。 相反，对部分数据进行采样以进行预测。 在这种情况下，预测可能是错误的，导致执行全表扫描。

在慢sql优化数据库中设置SQL慢查询

方法一：修改配置文件，在my.ini中添加几行：主要是慢查询的定义时间（超过2秒为慢查询），以及慢查询日志记录（ ）

[mysqlld]
//定义查过多少秒的查询算是慢查询，我这里定义的是2秒
long_query_time=2
#5.8、5.1等版本配置如下选项
log-slow-queries="mysql_slow_query.log"
#5.5及以上版本配置如下选项
slow-query-log=On
slow_query_log_file="mysql_slow_query. log"
//记录下没有使用索引的query
log-query-not-using-indexestpspb16glos dndnorte/t

方法二：通过MySQL数据库启用慢查询：

mysql>set global slow_query_log=ON
mysql>set global long_query_time = 3600;
mysql>set global log_querise_not_using_indexes=ON;

分析慢查询日志

# 可以使用以下命令来定位sql执行效率低的地方

展示;

# sql可以使用分析执行计划。

对执行计划的分析也是面试官喜欢考察的点。

采访者：你如何使用它？ 您是如何分析执行计划的？

这里简单讨论一下，稍后详细解答。 只需关注这些领域：

type：表示MySQL在表中查找所需行的方式，或者说访问类型

：表示查询可能使用的索引

key：实际使用的索引

：使用索引字段的长度

rows：扫描的行数

额外的：

如何优化慢SQL

对于MYSQL慢SQL语句的优化，我们还可以从几个方面来分析（基本全面覆盖）：

面试会考虑这几个方面：索引+sql语句+数据库结构优化+优化器优化+架构优化。

指数

1.尽量覆盖索引。 5.6支持索引下推。

2、组合索引遵循最左匹配原则

3. 避免索引失败

4、在写多读少的场景下，可以选择普通索引，而不是唯一索引。

更新时，可以使用普通索引进行优化，减少磁盘IO，将更新操作记录到缓冲区，然后当查询到来时将数据读取到内存中，然后进行修改。

5、索引构建原则（一般建在where和order by上，基数要大，分化程度要高，不要过度索引，外键上建索引）

SQL语句

1.分页查询优化

该方案适用于主键自增的表，可以将Limit查询转化为某个位置的查询。

* 来自其中id>20000限制10；

2.优化语句

数据库结构优化

1、将一个包含多个字段的表分解为多个表

有些字段使用频繁，有些字段使用频率较低。 当数据量较大时，会因使用频率低而变慢。 你可以考虑将它们分开。

2、对于经常联合查询的表，可以考虑建立中间表。

优化器优化

1.优化器使用MRR

原理：MRR【Multi-Range Read】按顺序读取ID或键值，将“随机磁盘读”转化为“顺序磁盘读”，减少磁盘IO，从而提高索引查询的性能。

mysql>set ='mrr=on';

查看额外还有一项 MRR

* 来自 10 岁和 20 岁的学生；

对于，去磁盘获取完整数据之前，会根据rowid进行排序，然后顺序读取磁盘。

对于，聚集索引会根据聚集索引键值进行排序，然后顺序读取聚集索引。

磁盘预读：请求一页数据时，还可以返回后面几页的数据，放入数据缓冲池。 这样，如果下次正好需要下一页数据，就不再需要从磁盘中读取了（局部性原则）

索引本身就是为了减少磁盘IO，加快查询速度，而MRR则进一步放大了索引减少磁盘IO的效果。

/p/

架构优化

读写分离（主库写，从库读）

总结：

1.先设置慢查询（my.ini或数据库命令）

2、分析慢查询日志

3. 定位低效SQL（显示）

4、分析执行计划（索引是否失效、索引是否使用、使用了哪些）

5、优化（索引+sql语句+数据库结构优化+优化器优化+架构优化）

今日一句话：

认识到一个人的灵魂是无法掌握的，这是智慧的最终成就。 人本身就是终极的奥秘。 ——王尔德

关注我的公众号“小龙”，我们一起讨论，帮助修改简历、解答问题、分析项目，只为帮助迷茫的你高效拿到心仪的offer！

大厂面试题及解析后续会更新。 大制造商的内部建议将直接提交给部门主管。 还会有一个交流群，供大家讨论共同进步。 继续努力吧！

往期回顾：

1.我的秋季招聘| 登陆大厂公司经历一（最后第二册）

2、阿里面试官：MYSQL是如何实现ACID的？

3、Mysql架构&事务原理及锁机制&MVCC日志（undo日志）两阶段提交&组提交