编写高效的sql可以给用户带来好的体验，需要开发这没有意识到这一点因为他们不关心也不知道怎么做。高效的sql可以给用户节省很多时间，这样就不需要dba来找上门，也不需要搭建RCA和性能调优。
性能不好的SQL有需要原因，其中之一是：全表扫描
-
什么时候应该用全表扫描
并不是说用全表扫描的方法来从表中获取数据是糟糕的方式，优化器选择全表扫描的方式而不选择索引的方式基于以下几点：
a)如果数据量特别大，使用索引的方式不一定会比全表扫描快；
b)如果查询表中所有的行（没有where）则优化器会选择全表扫描；
c)如果从表中检索大量数据，索引可能没有任何优势。
d)如果优化器没有准确的数据分布信息，它可能会选择错误的索引或根本没有索引；
e)如果where语句中的子查询包含的某些列，则可能导致索引不可用。
-
什么时候应该用索引
优化器选择索引扫描而不选择全表查询的情况基于以下几点：
a)where语句中的列与现有索引正好匹配；
b)有DISTINCT,UNION 和ORDER BY 则会用索引查询；
c)有主键与外键约束则也会用索引；
d)尽量避免使用order by 。
-
WHERE语句的陷阱
因为不好的where语句，可能导致扫描不走索引：
a)在WHERE子句中使用列，它与索引中的列顺序不匹配；
b)比较同一表中的列；
c)选择的列是low-selectivity indexes;
d)在其中一列使用了count然后让他与一个常量比较；
e)在其中一列使用function然后让他与一个常量比较；
f)使用了like
g)与null 做比较
h)使用了not
i)使用了转换值
j)使用了in
-
要编写好的SQL,请避免上面提到的陷阱并采纳以下建议：
a)范围的话尽量使用between and
b)如果外部查询有附件条件使用exists或not exists
c)如果没办法避免order by 则尽量使用索引列
Examples:
黄金法则
-
如果代码中包含算数表达式，尽量把他转换成求值的结果；
-
在列中避免使用functions
-
当你知道一组值的分布时候，尽量别使用<>而是把他转换为>和<的表达式；
-
把or 转换为in；
-
like 要比substring性能好；
-
尽量把union用or替代；
-
使用CASE来过滤最终的select list
-
where语句必须按照这些列在索引中出现的顺序使用；
-
使用子查询来代替join可以提高一些分组连接的性能；
-
使用distinct来代替group by；
-
尽量不在语句中使用distinct 和order by 除非你真的需要...
-
尽量不用outer join
-
子查询中的表如果可以通过from 与主表连接，则尽量别使用子查询；
-
所有的表或视图都应该有key field
-
尽量使用union all 来代替union;
- 我的公众号：
