介绍:
无论您是创建Web应用程序的开发人员,还是参与Web测试的DBA或测试人员,SQL方面的技巧在数据库编程和数据库验证中都非常重要。因此,我们整理了QL性能优化方面的面试问题。
SQL性能优化是一项艰巨的任务,并且是处理Web应用程序日益增加的负载的关键。
因此,我们有选择地选择了SQL性能优化方面的面试问题,这些问题可以使您充分了解SQL性能优化概念。
MySQL 基本是每个后台面试者必问的问题,而SQL优化又是MySQL中重之又重的一块了。如果你的SQL优化回答的好,有条理,那你入取的概率就大大提升了。
问:比如,现在有个面试官说,现在线上有个SQL执行很慢,你怎么优化?
这种时候最好分几步回答,不要一上来就说,该怎么怎么写SQL,面试时要学会,跳出来,看全貌,装进去,看本质。
问:慢 SQL 语句的几种常见诱因?
在这个时候,就可以说,面试官,您好,我觉得SQL慢出现的原因可以分为以下几种,切记,不要回答自己模糊不清的,没法自圆其说的即使知道你也别回答,不然就是给自己挖坑。。。
- 无索引、索引失效导致慢查询
如果表很大,而对where或者order by 后面字段没有建立索引,那这种情况查起来肯定很费力。但是有时候建立了索引,但在一些特定的场景下,索引还有可能会失效,所以索引失效也是导致慢查询的主要原因之一。失效场景很多,比如模糊查询白分号在前、查询的字段使用了函数或者做了计算操作都有可能导致索引失效。 - 锁等待
InnoDB 存储引擎支持行锁和表锁,我们要注意行锁升级为表锁的可能。在批量更新操作时,行锁就很可能会升级为表锁。MySQL 认为如果对一张表使用大量行锁,会导致事务执行效率下降,从而可能造成其它事务长时间锁等待和更多的锁冲突问题发生,致使性能严重下降,所以 MySQL 会将行锁升级为表锁。还有,行锁是基于索引加的锁,如果我们在更新操作时,条件索引失效,那么行锁也会升级为表锁。除了锁升级之外,行锁相对表锁来说,虽然粒度更细,并发能力提升了,但也带来了新的问题,那就是死锁。 - 不恰当的 SQL 语句
使用不恰当的 SQL 语句也是慢 SQL 最常见的诱因之一。例如,习惯使用 <SELECT >,<SELECT COUNT()> SQL 语句,在大数据表中使用 <LIMIT M,N> 分页查询,以及对非索引字段进行排序等等。对于一些慢的SQL,我该怎么分析?
上面我说了一些关于SQL执行慢的原因,下面就该看看怎么分析这些SQL了
- 找出慢SQL
开启慢查询,慢查询是分析SQL执行慢的常见手段,主要有这几个参数,slow_query_log:慢查询开启状态,slow_query_log_file:慢查询日志存放的位置(这个目录需要MySQL的运行帐号的可写权限,一般设置为MySQL的数据存放目录),long_query_time:查询超过多少秒才记录。 - 通过 EXPLAIN 分析 SQL 执行计划
- 通过 Show Profile 分析 SQL 执行性能
问:平时写SQL时该注意什么?有什么经验可谈?
到这里,如果面试官还在听你回答,这时候,你可以适当提高一点语气,说对于一些慢SQL,有很大一部分是由于我们开发者写SQL时不注意SQL优化导致的,那么我就说一下我知道的一些注意事项。。。(提高声音分贝,以防面试官睡着,并敲重点,告诉面试官,我准备装逼了,哈哈哈。。。)
- 统计时尽量使用count(*),count(*)≈count(1),大于count(主键)。
- 如果明确查找一条语句,请使用limit 1;,因为找到一条符合条件的记录后就不会继续查找了。
- 优化分页查询
- 避免 Select *
用到什么字段就具体写什么字段,原因除了 select * 查询所有字段会多出网络传