一、模糊查询效率很低：html
缘由：like自己效率就比较低，应该尽可能避免查询条件使用like；对于like ‘%...%’（全模糊）这样的条件，是没法使用索引的，全表扫描天然效率很低；另外，因为匹配算法的关系，模糊查询的字段长度越大，模糊查询效率越低。算法
解决办法：首先尽可能避免模糊查询，若是由于业务须要必定要使用模糊查询，则至少保证不要使用全模糊查询，对于右模糊查询，即like ‘…%’，是会使用索引的；左模糊likesql
‘%...’没法直接使用索引，但能够利用reverse + function index 的形式，变化成 like ‘…%’；全模糊是没法优化的，必定要的话考虑用搜索引擎。出于下降服务器的负载考虑，尽量地减小数据库模糊查询。数据库
二、查询条件中含有is null的select语句执行慢服务器
缘由： 9i中，查询字段is null时单索引失效，引发全表扫描。性能
解决方法：SQL语法中使用NULL会有不少麻烦，最好索引列都是NOT NULL的；对于is null，能够创建组合索引，nvl(字段,0),对表和索引analyse后，is null查询时能够从新启用索引查找,可是效率还不是值得确定；is not null 时永远不会使用索引。通常数据量大的表不要用is null查询。大数据
三、查询条件中使用了不等于操做符（<>、!=）的select语句执行慢优化
缘由：SQL中，不等于操做符会限制索引，引发全表扫描，即便比较的字段上有索引搜索引擎
解决方法：经过把不等于操做符改为or，可使用索引，避免全表扫描。例如，把column<>’aaa’，改为column<’aaa’ or column>’aaa’，就可使用索引了。spa
四、使用组合索引，若是查询条件中没有前导列，那么索引不起做用，会引发全表扫描；可是从Oracle9i开始，引入了索引跳跃式扫描的特性，能够容许优化器使用组合索引，即使索引的前导列没有出如今WHERE子句中。例如：create index skip1 on emp5(job,empno); 全索引扫描 select count(*) from emp5 where empno=7900; 索引跳跃式扫描 select /*+ index(emp5 skip1)*/ count(*) from emp5 where empno=7900; 前一种是全表扫描，后一种则会使用组合索引。
五、or语句使用不当会引发全表扫描
缘由：where子句中比较的两个条件，一个有索引，一个没索引，使用or则会引发全表扫描。例如：where A=：1 or B=：2，A上有索引，B上没索引，则比较B=：2时会从新开始全表扫描。
六、组合索引，排序时应按照组合索引中各列的顺序进行排序，即便索引中只有一个列是要排序的，不然排序性能会比较差。例如：create index skip1 on emp5(job,empno，date); select job，empno from emp5 where job=’manager’and empno=’10’ order by job,empno,date desc; 实际上只是查询出符合job=’manager’and empno=’10’条件的记录并按date降序排列，可是写成order by date desc性能较差。
七、Update 语句，若是只更改一、2个字段，不要Update所有字段，不然频繁调用会引发明显的性能消耗，同时带来大量日志。
八、对于多张大数据量（这里几百条就算大了）的表JOIN，要先分页再JOIN，不然逻辑读会很高，性能不好。
九、select count(*) from table；这样不带任何条件的count会引发全表扫描，而且没有任何业务意义，是必定要杜绝的。
十、sql的where条件要绑定变量，好比where column=：1，不要写成where column=‘aaa’，这样会致使每次执行时都会从新分析，浪费CPU和内存资源。
文章来源：http://www.dedecms.com/knowledge/data-base/sql-server/2012/0821/11698.html?jdfwkey=n3nuq
不要看他人高新，且看闲时谁在拼