大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说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代码100分
有如上表和数据，原来的运行的SQL 如下
代码100分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" ;假设修改后导致变慢了 ！
如果碰到，这类问题，该怎么办呢？
最简单的方法是比较修改前后的执行计划，
然后发现不同之处，修改成原来的执行计划就可以。
以这个案例为例，修改前：
代码100分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)发现执行计划改变了，
1.那我们可以使用hint 或者 视图巩固的方法进行固定就可以。
2.更深层的就需要分析统计信息，是否相对真实的反映了当前的数据量。
3.也有可能，如果数据倾斜比较严重，就需要引入直方图等等。
如果说，这些知识我都不会，我就想简单，直接，有效的方法，那怎么办呢？
以上述例子为例，就是单指有视图的情况！
添加一个 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: <derived2>
partitions: NULL
type: ref
possible_keys: <auto_key0>
key: <auto_key0>
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优化 ，数据核对
对文章感兴趣的朋友们可以加我哦，这里有一个乐于交友的人鸭！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/10794.html
