MySQL优化之慢查询优化基础

查询性能低下最基本的原因是访问数据太多，大部分性能低下的查询可以通过减少访问数据量的方式进行优化
对于低效的查询我们通过以下两个步骤进行分析

1. 确认应用程序是否在检索大量超过需要的数据。比如访问了太多的行和列
示例
(1).使用SELECT获取大量的数据集，客户端应用程序接受全部的结果集只接受前面一小部分并丢弃大量的数据，对此最简单有效方法是在这样查询的后面加上LIMIT
(2).多表关联时返回全部的列，比如查询在电影AcademyDinosaur出现的演员(三张表，演员表，电影表，电影演员表)

select * from sakila.actor
inner join sakila.film_actor using(actor_id)
inner join sakila.film using(film_id)
where sakila.film.title='Academy Dinosaur';

这个查询会返回这三个表的全部数据，正确方式是像下面这样只取需要的列

select sakila.actor.* from sakila.actor
inner join sakila.film_actor using(actor_id)
inner join sakila.film using(film_id)
where sakila.film.title='Academy Dinosaur';

(3).总是取出全部列
在使用SELECT * 这样的操作的时候，会让优化器无法完成索引覆盖扫描这类的优化，这会造成I/O，内存和CPU的消耗。不过为了增加代码的复用性SELECT * 却被广泛的使用，如果我们在了解SELECT *给应用程序所带来的影响情况下，这不是什么坏事
(4)重复查询相同的数据
比如用户头像的URL在很多场景下都被用到，第一次查询之后就应该将其缓存起来
2. 确认MySQL是否在分析大量超过需要的数据行
确认查询只返回需要的数据之后，接下来应该看看查询为了返回结果是否扫描过多的数据
衡量查询开销的指标有如下三个

• 响应时间
• 扫描行数
• 返回的行数
  这三个指标会被记录到MySQL的慢日志里，所以检查慢日志是找出扫描行数过多的好办法

(1)响应时间
响应时间分为服务时间和排队时间。服务时间是指数据库处理这个查询真正花费的时间，排队时间通常是I/O等待和锁等待花费的时间
(2)扫描的行数和返回的行数
理想情况下扫描的行数和返回的行数是相同的
(3)扫描的行数和返回类型
评估查询开销的时候，需要考虑一下从表中找到某行数据的成本。MySQL有好几种方式可以查找并返回一行结果，有些访问方式可能需要扫描很多行返回一行，有些可能无需扫描就能返回结果
EXPLAIN语句的type列反映了扫描类型，访问类型有全表扫描到索引扫描，范围扫描，唯一索引查询，常熟引用