深入理解MySQL慢查询优化(3) -- 案例实操

经过前面内容的理解，我们以及了解了MySQL的优化策略，以及SQL语句的执行流程，接下来我们通过一个问题来学习，如何优化SQL

1. 如何构造一条慢SQL

前面我们介绍了，数据库实现高效查询的核心原则是：增量查询和索引加速，其中索引加速很大程度上也是在为增量查询服务。

要构造一条慢SQL，我们就可以从破坏增量查询入手：

1.1 利用join制造大量计算

select * from employees join salaries 
       on employees.emp_no = salaries.emp_no 
limit 10;

优化思路：给内层表的join列(salaries.emp_no)加上索引，避免全表扫描内层表

1.2 添加where条件

select * from employees join salaries 
       on salaries.emp_no = employees.emp_no 
where salaries.salary > 60000
limit 10;

优化思路：在salaries.salary和employees.emp_no上各建一个索引，实际执行的时候，MySQL就可以先利用salaries.salary上的索引，定位到大于60000的数据，再把salaries作为外层表和employees表join，同时employees表也可以使用 employees.emp_no 定位到需要的数据，这样就消除了where的难度。

1.3 添加多个where条件

select * from employees join salaries 
       on salaries.emp_no = employees.emp_no 
where salaries.salary > 60000 
       and salaries.from_date > '1992-07-12'
limit 10;

优化思路：这里where条件都是同一个表的，可以创建salary和from_date的联合索引，查询时MySQL就可以更具salary和from_date上的联合索引找出 salary > 60000并且from_date > '1992-07-01' 的数据，然后再把salaries作为外层表和内存进行join；如果where条件过多或者并非同一个表的字段，则可以对每个where条件的字段都创建一个索引，使用实际效果好的那一个索引，不推荐使用多个不同的索引共同筛选，因为回表操作的开销无法忽略

1.4 使用left join限制join的顺序

select * from employees left join salaries 
       on salaries.emp_no = employees.emp_no 
where salaries.salary > 60000
       and salaries.from_date > '1992-07-12'
limit 10;

优化思路：这里使用了left join看似强行把employees指定为了外层表，但是，left join 仅比join多了内层表为null的数据，但上述SQL语句中，存在where条件 salaries.salary > 60000 ，null > 60000一定为false，于是这里的left join就和join每什么区别了，MySQL就会把这个left join优化为join，我们就可以继续使用上面第3点的优化思路

1.5 引入order by 破坏增量策略

select * from employees join salaries 
       on salaries.emp_no = employees.emp_no 
where salaries.salary > 60000
order by salaries.from_date
limit 10;

这里的where和order by使用了不同的列，会涉及索引的选择问题：

• 如果where筛选效果好，那么就使用where字段上的索引，先筛选得出结果再排序，比如只有几百条记录符合条件，那对几百条数据做个排序开销也不大。
• 如果where筛选效果不好，就使用order by字段上的索引，那么就可以继续使用增量策略，按顺序查找符合条件的数据，收集到10条就返回
• 如果where筛选效果不好不坏，并且表的数据量巨大，如果先筛选后排序，筛选后的数据量多，让 sort buffer放不下，排序开销就足够大；如果使用order by上的索引顺序搜索，搜索的很多数据都不符合where条件，需要大量搜索才能凑出10条数据，至此我们成功构造出了一条慢SQL

通过上面的分析我们可以看到，数据库的增量略是相当成功的， 想制造一条慢SQL是并不容易的。

这里再次提醒一点，MySQL 数据库通常不适合全量扫描的场景，特别是当表的数据量非常大时。全量扫描（即全表扫描）会导致高 I/O 负载和长时间的查询执行，这对性能和资源消耗都有较大影响，所以使用MySQL通常会使用分页查询。如果业务需要大量的全量扫描则可以考虑使用其他数据库，例如NoSQL。同时MySQL也不适合统计类的查询，比如 sum/avg等，这类查询天然和增量策略冲突

2. 案例练习 

相信有了前面的学习，我们已经对如何分析并优化一条SQL语句有了较深的了解，下面我们尝试分析几个案例：

2.1 案例一

-- cost 364ms
SELECT * FROM employees JOIN salaries ON employees.emp_no = salaries.emp_no 
                AND salaries.from_date = '1992-08-04' 
WHERE employees.emp_no > 10005 AND salaries.salary > 70000 
ORDER BY salaries.salary 
LIMIT 10;  

-- employees: PRIMARY KEY(emp_no)
-- salaries: PRIMARY KEY(emp_no, from_date)

-> Limit: 10 row(s)
    -> Sort: salaries.salary, limit input to 10 row(s) per chunk
        -> Stream results  (cost=95578 rows=74834)
            -> Nested loop inner join  (cost=95578 rows=74834)
                -> Filter: (employees.emp_no > 10005)  (cost=29971 rows=149667)
                    -> Index range scan on employees using PRIMARY over 
                                (10005 < emp_no)  (cost=29971 rows=149667)
                -> Filter: (salaries.salary > 70000)  (cost=0.338 rows=0.5)
                    -> Single-row index lookup on salaries using PRIMARY 
                                (emp_no=employees.emp_no, from_date=DATE'1992-08-04')  
                                (cost=0.338 rows=1)

这里的执行策略是：

• 1. 通过employees.emp_no上的索引查询 10005 < emp_no，然后筛选出 10005 < emp_no的数据
• 2. 对外层表的每条数据通过salaries.emp_no和salaries.from_data上的联合索引 查符合条件emp_no=employees.emp_no, from_date=DATE'1992-08-04'的数据，然后筛选出 salaries.salary > 70000的数据
• 3. 把内外层表的数据做连接操作
• 4. 匹配完所有数据后，把结果集按照salaries.salary字段进行排序，然后返回前10条

优化思路：上面执行策略显然没有使用增量策略，是匹配完所有的数据后再进行排序后返回，于是我们可以在salaries.salary字段上添加索引，使查询时，可以把salaries作为外层表进行查询，就可继续使用增量策略，查询到10条后返回

优化后的执行策略：

-> Limit: 10 row(s)  (cost=443853 rows=10)
    -> Nested loop inner join  (cost=443853 rows=1.42e+6)
        -> Index range scan on salaries using idx_salary over (70000 < salary), with index condition: 
               ((salaries.from_date = DATE'1992-08-04') and (salaries.emp_no > 10005) and (salaries.salary > 70000)) 
            (cost=284192 rows=1.42e+6)
        -> Single-row index lookup on employees using PRIMARY (emp_no=salaries.emp_no)  (cost=0.25 rows=1)

这里的执行策略是：

• 1. 根据索引 salaries.salary字段上的索引查询 70000 < salary的数据，然后更具条件(salaries.from_date = DATE'1992-08-04') and (salaries.emp_no > 10005) and (salaries.salary > 70000))进行筛选
• 2. 根据employees.emp_no 上的索引，查找符合emp_no=salaries.emp_no 的数据
• 3. 进行join操作，当收集到10条数据后会直接返回

 2.2 案例二

-- 耗时4200ms
select * from employees
   left join salaries on employees.emp_no = salaries.emp_no
   left join dept_emp on dept_emp.emp_no = employees.emp_no 
where dept_emp.dept_no not in (select dept_no from departments where dept_name > 'AAA')
order by employees.hire_date 
limit 10;
-- employees: PRIMARY KEY (emp_no)
-- salaries: PRIMARY KEY (emp_no, from_date)
-- dept_emp: PRIMARY KEY (emp_no,dept_no)
-- departments: UNIQUE KEY (dept_name)

尝试使用增量策略 -- 4500ms 

 给 employees.hire_date加索引：

-> Limit: 10 row(s)  (cost=851920 rows=10)
    -> Filter: <in_optimizer>(dept_emp.dept_no,dept_emp.dept_no in (select #2) is false)  (cost=851920 rows=10.4)
        -> Nested loop left join  (cost=851920 rows=10.4)
            -> Nested loop left join  (cost=135044 rows=9.42)
                -> Index scan on employees using idx_hire_date  (cost=776e-6 rows=1)
                -> Index lookup on salaries using PRIMARY (emp_no=employees.emp_no)  (cost=0.451 rows=9.42)
            -> Index lookup on dept_emp using PRIMARY (emp_no=employees.emp_no)  (cost=0.254 rows=1.1)
        -> Select #2 (subquery in condition; run only once)
            -> Filter: ((dept_emp.dept_no = `<materialized_subquery>`.dept_no))  (cost=2.9..2.9 rows=1)
                -> Limit: 1 row(s)  (cost=2.8..2.8 rows=1)
                    -> Index lookup on <materialized_subquery> using <auto_distinct_key> (dept_no=dept_emp.dept_no)
                        -> Materialize with deduplication  (cost=2.8..2.8 rows=9)
                            -> Filter: (departments.dept_name > 'AAA')  (cost=1.9 rows=9)
                                -> Covering index scan on departments using dept_name  (cost=1.9 rows=9)

可以看到索引生效了，但是耗时确没减少还略有增加，这是因为，符合条件的数据，没有10条，这种情况下，增量和全量没区别，走索引还会增加回表的开销所以，走索引不一定快，需要具体分析执行逻辑。

拆分sql 

在上面的sql的执行策略中，对于每个可能的结果都是最后判断是否满足，not in，并且所有满足条件的数据又不超过10条，就会大致大量的数据都会去使用dept_emp.dept_no和not in中的值比较，又因为dept_emp在第三层循环，所以回导致同一个dept_emp.dept_no会去not in中比较很多次，这里我们可以通过把dept_emp当作外层表，先满足 not in 条件再向后匹配。当not in中包含的是具体的常量值，MySQL通常就会在查询中首先处理这些常量值

-- 耗时2ms，返回 'd009','d005','d002','d003','d001','d004','d006','d008','d007'
select dept_no from departments where dept_name > 'AAA';

-- 把第一步返回的结果直接做为第二步查询的条件，耗时3ms
select * from employees
   left join salaries on employees.emp_no = salaries.emp_no
   left join dept_emp on dept_emp.emp_no = employees.emp_no 
where dept_emp.dept_no not in ('d009','d005','d002','d003','d001','d004','d006','d008','d007')
order by employees.hire_date 
limit 10;
-- employees: PRIMARY KEY (emp_no)
-- salaries: PRIMARY KEY (emp_no, from_date)
-- dept_emp: PRIMARY KEY (emp_no,dept_no)    
-- departments: UNIQUE KEY (dept_name)

3. 常用优化技巧

• 1. 添加合适的索引：尽量保证order by，join，group by，where有合适的索引可以用
• 2. 在列上调用函数或者做计算会导致索引用不了：

  -- 列上做计算，耗时400ms
  select * from salaries where emp_no - 10 = 11111;
  -- where条件值上做计算，耗时3ms
  select * from salaries where emp_no = 11121;

• 3. 使用limit限制返回条数：有利于发挥增量查询的优势
• 4. 避免使用select *，而是明确列出实际需要的列：减少MySQL需要抓取的列，提升性能；有可能消除回表的开销 如果查询走了二级索引，用select * 必须回表；有时候，实际需要的列，索引上都有，就可以节省掉回表的开销