本文主要是介绍有过MySQL调优经验吗【面试题】,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
写作目的
MySQL这块除了索引等八股文外,MySQL调优就是面试中的重点和难点,回答的闭环性很重要,本文提供回答思路及真实的生产案例。一起卷。
回答思路
发现SQL
目的:什么的原因让你去做个事情
我们一般调整的是慢SQL。什么叫慢SQL,是执行的时间超过阈值后的SQL叫慢SQL,这个SQL会保留在慢SQL日志里。
- 我们公司会定期的做安全生产,对这慢SQL日志一块进行总结和分析,从而发现了需要优化的慢SQL.我们公司的慢SQL阈值是1秒。
- 线上问题会有工单,工单我们会去复现,然后拿着trace(类似下图)会复现,此时就可以定位到慢SQL。
分析SQL
SQL慢有两种
- SQL写的比较差。比如不走索引或者没索引。本文讨论这一种。
- 一种是数据量大,就应该慢。
使用Explian命令可以查看使用的使用。如下图所示,我们可以看到可能使用到的索引possible_keys和实际使用到了索引key。从而确定索引是否合理,SQL是否合理。
-
索引不合理
索引建的列没有区分度(比如男女),索引最好建多列索引。 -
SQL不合理
SQL查询的字段太多,SQL的where条件顺序乱
生产案例
mysql的limit查询竟然有坑
业务解决技术问题
比如分页场景,我现在的SQL 如下。
SELECT * FROM tb_creative where id in (40个)
在有索引且数据量大的情况下,其实优化SQL是没有办法(能做的都做了)。
- 业务解决
可以从业务角度解决问题,我每页20,那这个这个SQL就会快一些。
SELECT * FROM tb_creative where id in (20个)
- 偏技术解决
把SQL拆开,千万别用并发(重点是没有串行快)
SELECT * FROM tb_creative limit id in (前20个)
SELECT * FROM tb_creative limit id in (后20个)
总结
面试回答的时候要有理有据。
- 有理:慢SQL日志、explain关键字、发现优化SQL的原因
- 有据:你公司的慢SQL阈值是多少(没有可以背个默认值);使用explain生产案例;数据量大的情况下拆SQL。
当然,数据大了可以分布式。
分布式主键:分布式主键生成策略
分库分表:HASH
分布式事务:分布式事务
说完了,面试官就顺其自然的问下面的问题了。然后半小时过去了,嘻嘻。
这篇关于有过MySQL调优经验吗【面试题】的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!