数据库慢查询优化的一个回答
之前字节二面的一个问题,个人觉得答的尚可,记录一下答案欢迎评论区指正和补充
回答:
首先我们分情况讨论,对于我们索引,首先explain打一下查询计划,看看key字段走的是哪个索引,如果出现回表的情况是否可以优化,然后如果是联合索引就看看len字段走了几个索引,当然最重要还是看type字段是否走了索引。然后我们针对性的对索引失效,或者回表等情况优化。
然后深分页也会导致一个慢查询的情况,尤其是limit字段,有两种方式一个是建立子查询先把主键id查出来然后根据id走索引,还有就是像你们抖音短视频下拉刷新这个分页场景,可以把利用游标的方式将上一次查询的主键id作为下一次查询的参数传入优化我们的查询
当然我们数据库的sql语句也可以优化,比如为了方便我们数据库的连接join操作可以先将我们查询的字段先进行限制和投影,减少我们连接操作涉及的字段
当然我们抛开业务取谈设计也不可取,对于特定业务可以进行反范式的设计,引入一些冗余字段,特别是像商品spu和sku这种聚合查询的情况
#字节跳动# #后端#
回答:
首先我们分情况讨论,对于我们索引,首先explain打一下查询计划,看看key字段走的是哪个索引,如果出现回表的情况是否可以优化,然后如果是联合索引就看看len字段走了几个索引,当然最重要还是看type字段是否走了索引。然后我们针对性的对索引失效,或者回表等情况优化。
然后深分页也会导致一个慢查询的情况,尤其是limit字段,有两种方式一个是建立子查询先把主键id查出来然后根据id走索引,还有就是像你们抖音短视频下拉刷新这个分页场景,可以把利用游标的方式将上一次查询的主键id作为下一次查询的参数传入优化我们的查询
当然我们数据库的sql语句也可以优化,比如为了方便我们数据库的连接join操作可以先将我们查询的字段先进行限制和投影,减少我们连接操作涉及的字段
当然我们抛开业务取谈设计也不可取,对于特定业务可以进行反范式的设计,引入一些冗余字段,特别是像商品spu和sku这种聚合查询的情况
#字节跳动# #后端#
全部评论
在explain之前还可以先看一下慢查询日志,比如mysql可以设置慢查询的阈值并且拿到执行时长超过阈值的sql,日志有锁竞争的时间,如果锁竞争的时间太长可以从并发的方向入手优化,之后再常规优化索引之类的。
美团技术有一个写的很详细的技术文章,关于慢查询的解决办法
慢查询会导致N个数据库连接Hang住,MySQL Server(数据库服务)的连接数是有限的,如果所有连接被慢查询占住,然后客户端又不断想要获取连接发送SQL,逐渐恶化,对用户的体验就是功能无法正常使用,不断报错,而MySQL Server也可能会被打挂掉。
相关推荐