sql优化初步学习笔记

sql性能优化的9条经验

1、查询的模糊匹配

尽量避免再一个复杂查询里面使用LIKE‘%parm1%’，百分号会导致相关列的索引无法使用，最好不要用
解决办法，只要对该脚本粗略改进，查询速度提升百倍
- a、修改前台程序–把查询条件的供应商名称一栏由原来的文本输入改为下拉列表，用户模糊输入供应商名称是，直接在前台就能帮忙定位到具体的供应商，这样在调用后台程序是，这列就可以直接用等于来关联了
b、直接修改后台–根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里面，然后再用临时表做复杂关联

2、索引问题

在做性能跟踪分析过程中，经常发现有不少后台程序的性能问题是因为缺少合适索引造成的，有些表甚至一个索引都没有。这种情况旺旺都是因为在设计表时，设法定义索引，而开发初期，由于表的记录很少，是索引创建于否，极可能对性能没啥影响，开发人员因此也未多加重视。然而一旦程序发布到生产环境，随着时间的推移，表的记录越来越多，这时缺少索引，对性能的影响遍越来越大
解决办法：
不要在建立索引的数据列上进行如下操作
- 避免对索引字段进行计算操作
- 避免在索引字段使用not <> !=
- 避免在索引列上使用IS NULL ,IS NOT NULL
- 避免在索引列上出现数据类型转换
- 避免在索引列上使用函数
- 避免在简历索引的列中使用空值

3、复杂操作

部分UPDATE ,SELECT 语句，写得很乏咋–可以考虑适当拆分几步，先生成临时表，在进行关联操作

4、update

同一个表的修改在一个过程里出现好几次，这类脚本可以整合为一个update语句完成

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

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

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

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

7、对where语句的法则

a、避免在where子句中使用in，not in ，or ，having
可以使用exist和not exist 代替in和not in
可以使用表连接代替exist，having可以使用where代替，如果不行，分两步处理
eg:

--select * from orders where customer_name not in (select customer_name form customer)
-->select * from orders where not exist(select cunstomer_name from customer)

b、不要以字符格式声明数字，要以数字格式声明字符。
eg

--select emp.name,emp.job from emp where emp.empno = 7369;
不要用-->select emp.name,emp.job from emp where emp.empno ='7369'

8、排序

避免使用耗费资源的操作，带有distinct ，union，minus，intersect，order by的sql语句会启动sql引擎，

9、慎用临时表