SQL性能优化十条

1、查询的模糊匹配

尽量避免在一个复杂查询里面使用LIKE'%param%'---红色标识位置的百分号会导致相关列的索引无法使用，最好不要用，解决办法：

1）修改前台程序——把查询条件的供应商名字一栏由原来的文本输入改成下拉列表，用户模糊输入供应商名字时，直接在前台定位到具体的供应商，这样再调用后台程序时，这列就可以直接用等于来关联了

2）直接修改后台——根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里头，然后再用临时表去做复杂关联

2、索引问题

在做性能跟踪分析过程时，经常发现有不少后台程序的性能问题是因为缺少合适的索引造成的，有些表甚至一个索引都没有，这种情况都是因为在设计表时，没去定义索引，而开发初期，由于表记录较少，索引创建与否可能对性能影响不大，开发人员因此也未曾多加重视，然一旦程序发布到生产环境，随着时间的推移，表数据越来越多，这时缺少索引，对性能的影响便会越来越大。

法则：不要再建立的索引的数据列上进行下列操作

1）避免对索引字段进行计算操作

2）避免在索引字段上使用not，<>，!=

3）避免在索引列上出现数据类型转换

4）避免在索引字段上使用函数

5）避免建立索引的列中使用空值

3、复杂操作

部分update、select语句写的很复杂（嵌套多级子查询）——可以考虑适当拆成几步，先形成一些临时数据表，再进行关联操作

4、update

在同一个表里的修改出现过很多次

update table1
set col1=…
where col2=…;
update table1
set col1=…
where col2=…
……

像这类脚本其实可以很简单就整合在一个update语句来完成

5、在可以使用union all语句里使用了union

union因为会将各查询子集的记录作比较，故比起union all，通常速度都会慢上许多。一般来说，如果使用union all能满足要求得话，务必使用union all。还有一种情况，虽然是要求几个子集的并集需要过滤重复记录，但由于脚本的特殊性，可能不存在重复记录，这时应该使用union all

6、在where语句中，尽量避免对索引字段进行计算操作

这个常识相信绝大部分开发人员都应该知道，但仍有不少人这么使用，我想其中一个最主要的原因就是为了编写简单而损害了性能

7、对where语句的法则

1）避免在where子句中使用in、not in、or或者having，

可以使用exist和not exist代替in和not in

可以使用表链接代替exist，having可以用where代替

例子

select * from orders where customer_name not in

(select customer_name from customer)

优化

select * from orders where customer_name not exist

(select customer_name from customer)

2）不要以字符串格式声明数字，要以数字格式声明字符值，否则会使索引无效，产生全表扫描

正例：select * from a where num = 123

反例：select * from a where num = '123'

8、排序

避免使用耗费资源的操作，带有distinct、union、minus、intersect、order by的语句会启动sql引擎执行，耗费资源的排序（sort），distinct需要一次排序操作，而其他的至少需要执行两次排序

9、临时表

慎重使用临时表可以极大地提高系统性能