74-MySQL

74-MySQL,第1张

面试问题—SQL和索引的优化问题


我们使用explain去分析SQL语句
但是真正的企业级项目有上千条万条SQL
我们不可能从头开始一条一条explain去分析。也不是所有的SQL都慢。

explain分析行不通。

正常的流程:

从什么地方可以获取那些运行时间长,耗性能的SQL,然后再用explain去分析它???
我们可以打开慢查询日志:
根据具体的业务和并发量来预估1个时间,比如说100毫秒,20毫秒,设置好后开启业务,压测过程中,如果打开慢查询日志,就会看到超过执行时间的SQL,然后就用explain
步骤如下:
1、设置合理的、业务可以接受的慢查询时间
2、压测执行各种业务
3、查看慢查询日志,找出所有执行耗时的SQL语句
4、用explain分析这些耗时的SQL语句
5、举例子
比如说:

  • 在where加order by,explain时发现有using filesort 外部排序,数据都是在磁盘上放,没有建立合适的索引的话,只能进行外部排序了。
  • 用where过滤条件和order by排序的字段建立联合索引。
  • 没有加索引,索引没用到,类型强转,过滤条件用了MySQL的函数,都用不到索引,要优化。

    举例子:
  • 自己在做业务的时候,用到了where和order by,使用explain分析,发现有using filesort,涉及到了外部排序。因为索引和数据都在磁盘上放着的,如果没有建立合适的索引,还要进行order by,只能外部排序,比较耗时。使用where的过滤条件和order by排序的字段建立联合索引。
  • 没有用到索引的情况:类型强制转换,mysql函数;考虑优化一下。
慢查询日志

slow_query_log

MySQL可以设置慢查询日志:

  • 当SQL执行的时间超过我们设定的时间,那么这些SQL就会被记录在慢查询日志当中;
  • 然后我们通过查看日志,用explain分析这些SQL的执行计划,来判定为什么效率低下;
  • 是没有使用到索引?还是索引本身创建的有问题?或者是索引使用到了,但是由于表的数据量太大,花费的时间就是很长,那么此时我们可以把表分成n个小表,比如订单表按年份分成多个小表等。

慢查询日志相关的参数如下所示:
(MySQL定义的很多的全局的开关,都是在全局变量中存储,可以用show/set variables查看或者设置全局变量的值)

慢查询日志开关: 默认是关闭的。
慢查询日志的路径: 默认在数据路径。

慢查询日志记录了包含所有执行时间超过参数 long_query_time(单位:秒)所设置值的 SQL语句的日志,在MySQL上用命令可以查看,如下:

这个值是可以修改的,如下:

现在修改成超过1秒的SQL都会被记录在慢查询日志当中!可以设置为0.01秒,表示10毫秒。
慢查询日志,默认名称是host_name-slow.log,存放在MySQL的数据路径下,内容格式显示大致如下:

通过查询慢查询日志,发现项目运行过程中,上面这条SQL语句的执行时间超过了设定的慢查询时间,那么接下来就需要用explain分析一下该SQL的执行计划了,根据具体情况找出SQL和索引该怎么去优化。

show profiles命令可有查看sql具体的运行时间,全局变量的名字是:profilin

举例:

体现不出时间!!!
像这种查询的时间在小数点后2位也体现不出来运行时间,如果想再优化它,就要使用profiling


会把之前所做的所有的SQL语句 *** 作的耗时时间显示出来。精确度还是很高的。我们可以根据它来进行更加的优化措施。
Query_ID是查询的标号。duration是耗时的时间。query是具体的SQL语句。

举例



global就是全局的,只要和同一个mysql server连接,都是有影响的。


默认执行时间为10s,超过该事件就会记录对应SQL语句。

将时间修改为0.1s:

我们在另外一个mysql client 查看一下:

慢查询日志的开关是全局的!!!

但是这样的时间变量的改动只是对当前的mysql client起作用而已,时间还是默认的10s。

举例:

我们的t_user表有200万个数据,来测试看看:



XSHELL换配色了哈哈!!!


做了整表的搜索。把主键索引树整个扫了一遍。
我们应该给password添加索引。然后记得password是字符串格式的书写哦。因为如果涉及类型转换是用不了索引的。

当然,这里也是用不到索引的,因为password本身就是没有索引的。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/737575.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-04-28
下一篇 2022-04-28

发表评论

登录后才能评论

评论列表(0条)

保存