一、前言
每个程序员的身上，都背负着几行祖传代码，这些代码，没有注释，令人久久寻味
这不就在前几天，上家公司的同事突然找到我，晒出了我的一句祖传 sql.....
二、情节对话
图1：
图2：
说实话，当时看到这句sql的时候，我的心情是这样的
“ 这个真的是我写的? ”
“ 我写这玩意干啥? ”
“ 这么多的查询嵌套和计算效率会不会太低? ”
“ 我自己都看哭了，他能看懂吗? ”
...
一连串的自问自答，我想起来了，是由于之前的某张统计表设计的不太合理，导致表内数据时间段内冗余较多，而统计展示又要很精细，所以逼出了我的这句祖传sql，嗯，都是表设计的锅，哈哈哈，甩锅成功！
其实当时，只要稍稍改一下表设计和统计入数据的代码逻辑，那么此处的sql就简单了，但是我太懒了，不想改别人的设计，也不想改别人的代码，所以只能苦了我的这位同事了。大家 以我为戒，切勿跟风
三、题外：你的sql太慢了，应该如何优化？
1、统一SQL语句的格式
如，对于以下两句SQL语句，很多人认为是相同的，但是，数据库查询优化器认为是不同的。
select * from student
select * From student
虽然只是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划。
所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！
2、少用 * ，用具体的字段列表代替“*”，不要返回用不到的任何字段
3、对查询进行优化，应尽量避免全表扫描
1）应考虑在 where 及 order by 涉及的列上建立索引。
2）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where score is null
可以在score上设置默认值0，确保表中score列没有null值，然后这样查询：
select id from t where score=0
3）应尽量避免在 where 子句中使用!=或<>操作符，否则将导致引擎放弃使用索引而进行全表扫描
4）应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
5）慎用in 和 not in，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6）合理使用like模糊查询
有时候需要进行一些模糊查询，如：
select * from contact where username like ‘%yue%’
关键词 %yue%，由于yue前面用到了“%”，因此该查询必然走全表扫描，除非必要，否则不要在关键词前加%
7）应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
8）应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：查询name以abc开头的id
select id from t where substring(name,1,3)='abc'
应改为:
select id from t where name like 'abc%'
4、用 exists 代替 in
很多时候用 exists 代替 in 是一个好的选择，Exists只检查存在性，性能比in强很多。例：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
5、不要把SQL语句写得太长，太过冗余、要简洁；能用一句千万不要用两句
6、考虑使用“临时表”暂存中间结果
简化SQL语句的重要方法就是采用临时表暂存中间结果，但是，临时表的好处远远不止这些，将临时结果暂存在临时表，后面的查询就在tempdb中了，
这可以避免程序中多次扫描主表，也大大减少了程序执行中“共享锁”阻塞“更新锁”，减少了阻塞，提高了并发性能。
7、注意所以字段作为条件
在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，
否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
8、尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销
因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
9、尽可能的使用 varchar 代替 char ，因为首先变长字段存储空间小，可以节省存储空间， 其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些
10、避免频繁创建和删除临时表，以减少系统表资源的消耗
11、尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写
12、尽量避免大事务操作，提高系统并发能力
13、尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理
14、选择最有效率的表名顺序
数据库的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表将被最先处理，在FROM子句中包含多个表的情况下,
你必须选择记录条数最少的表放在最后，如果有3个以上的表连接查询,那就需要选择那个被其他表所引用的表放在最后。
1）如果三个表是完全无关系的话，将记录和列名最少的表，写在最后，然后依次类推
2）如果三个表是有关系的话，将引用最多的表，放在最后，然后依次类推
15、用TRUNCATE替代DELETE
16、用WHERE子句替换HAVING子句
17、使用内部函数提高SQL效率
18、注意WHERE子句中的连接顺序
数据库采用自右而左的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之左,
那些可以过滤掉最大数量记录的条件必须写在WHERE子句的之右。
【备注】：看完记得优化自己的sql，别被同事追着打，哈哈哈
