SQL优化很难怎么办？给你一个简单暴力的办法

今天给大家带来一个比较简单SQL优化案例，来分析一下开发人员经常感到不解一个问题——视图合并导致的SQL变慢

例如：
一个运维人员（这里的运维指的是，在现有的系统上，进行稍微修改）
因为业务上的改变，在原有的SQL上添加了一个条件，结果原来运行很快的SQL有可能变慢，甚至会发生time out （当然导致这种情形的原因很多，种类也比较多）这里只讨论一种情况即视图合并导致的SQL变慢。
本文讲的只是一种情况，若想从根本上解决这类问题，需要熟练掌握执行计划。

CREATE TABLE `salaries09` (
 id bigint not null auto_increment primary key ,
 `emp_no` int(11) NOT NULL,
 `salary` int(11) NOT NULL,
 `from_date` date NOT NULL,
 `to_date` date NOT NULL,
 KEY ix_t1 (`emp_no`,`from_date`),
 KEY `emp_no` (`emp_no`),
 KEY `from_date` (`from_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

有如上表和数据，原来的运行的SQL 如下

select * from ( select * from salaries09 where emp_no between 10001 and 10101 order by emp_no )v ;

若原来的SQL 会运行很快，没有问题。

但由于后来业务上的改变需要添加一些条件

修改之后的SQL 如下

select * from ( select * from salaries09 where emp_no between 10001 and 10101 order by emp_no )v where from_date = "1986-06-26" ;

假设修改后导致变慢了 ！
如果碰到，这类问题，该怎么办呢？

最简单的方法是比较修改前后的执行计划，

然后发现不同之处，修改成原来的执行计划就可以。

以这个案例为例，修改前：

root@mysql3306.sock>[employees]> desc select * from (
 -> select * from salaries09 where emp_no between 10001 and 10101 order by emp_no
 -> )vG
*************************** 1. row ***************************
 id: 1
 select_type: SIMPLE
 table: salaries09
 partitions: NULL
 type: range
possible_keys: ix_t1,emp_no
 key: ix_t1
 key_len: 4
 ref: NULL
 rows: 13704
 filtered: 100.00
 Extra: Using index condition
1 row in set, 1 warning (0.00 sec)

修改后：

root@mysql3306.sock>[employees]> desc select * from (
 -> select * from salaries09 where emp_no between 10001 and 10101 order by emp_no
 -> )v where from_date = "1986-06-26" G
*************************** 1. row ***************************
 id: 1
 select_type: SIMPLE
 table: salaries09
 partitions: NULL
 type: ref
possible_keys: ix_t1,emp_no,from_date
 key: from_date
 key_len: 3
 ref: const
 rows: 8
 filtered: 3.80
 Extra: Using index condition; Using where; Using filesort
1 row in set, 1 warning (0.00 sec)

发现执行计划改变了，

那我们可以使用hint 或者 视图巩固的方法进行固定就可以。

更深层的就需要分析统计信息，是否相对真实的反映了当前的数据量。

也有可能，如果数据倾斜比较严重，就需要引入直方图等等。

如果说，这些知识我都不会，我就想简单，直接，有效的方法，那怎么办呢？

以上述例子为例，就是单指有视图的情况！

添加一个 limit 10000000000000

至少大部分情况下能保证：假设原来的SQL很快，修改之后也很快。

修改成如下 ：

desc select * from ( select * from salaries09 where emp_no between 10001 and 10101 order by emp_no limit 10000000000000 )v where from_date = "1986-06-26" G
*************************** 1. row ***************************
 id: 1
 select_type: PRIMARY
 table: 
 partitions: NULL
 type: ref
possible_keys: 
 key: 
 key_len: 3
 ref: const
 rows: 10
 filtered: 100.00
 Extra: NULL
*************************** 2. row ***************************
 id: 2
 select_type: DERIVED
 table: salaries09
 partitions: NULL
 type: range
possible_keys: ix_t1,emp_no
 key: ix_t1
 key_len: 4
 ref: NULL
 rows: 13704
 filtered: 100.00
 Extra: Using index condition
2 rows in set, 1 warning (0.00 sec)

如此也能解决问题！

本文节选自松华老师的《SQL优化专栏》

郑松华，知数堂SQL 优化班老师

现任 CCmediaService DBA，主要负责数据库优化相关工作

擅长SQL优化 ，数据核对

对文章感兴趣的朋友们可以加我哦，这里有一个乐于交友的人鸭！