一些SQL性能优化的实用经验_%param1% sql-优快云博客

1、查询的模糊匹配

尽量避免在一个复杂查询里面实用LIKE '%param1%'

解决办法：

其实只要对该脚本略作改进，查询速度就会提升近百倍。改进方法如下：

修改前台程序。把查询条件的栏目有文本输入改为下拉列表，用户输入模糊关键字时，直接在前台帮忙定位到具体的关键字，这样在调用后台程序时，就可以等于直接关联了。
直接修改后台。根据输入条件，先查找出符合条件的关键字，并把相关记录保存在一个临时表中，然后再用临时表去做复杂关联

2、索引问题

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

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

避免对索引字段进行计算操作
避免在索引字段上使用NOT，<>，!=
避免在索引苦厄上使用IS NULL和IS NOT NULL
避免在索引列上出现数据类型转换
避免在索引字段上使用函数
避免建立索引列中使用空值

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语句中，尽量避免对索引字段进行计算操作

有大量后台层序存在类似用法，如：
where trunc(create_date)=trunc(:date1)
虽然已经对create_date字段建立了索引，但由于加了TRUNC，使得索引无法用上。此处正确的写法应该是

where create_date>=trunc(:date1) and create_date<?xml:namespace prefix = trunc( />< PRE></trunc(:date1)+1>

或者是
where create_date between trunc(:date1) and trunc(:date1)+1-1/(24*60*60)

注意：因为between的范围是个闭区间，故严格意义上应该减去一个趋于0的小数，这里暂且设置成减去1秒(1/(24*60*60))，如果不要求这么精确的话，可以略掉这步。

7、对WHERE语句的法则

避免在WHERE子句中使用in、not in、or或者having
可以使用exist或not exist代替in和not in。

可以使用表链代替exist。having可以用where代替，如果无法代替可以分成两步处理
SELECT * FROM orders WHERE customer_name NOT INT (SELECT customer_name FROM customer)
优化如下：
SELECT * FROM orders WHERE customer_name not exist(SELECT customer_name FROM customer)
不要以字符形式声明数字，要以数字格式声明字符值，日期同样，否则会使索引无效，产生全表查询，如：
使用：
SELECT emp.ename, emp.job FROM emp WHERE emp.empno = 7369;
不要使用：
SELECT emp.ename,emp.job FROM emp where emp.emno='7369'