原文链接来自:面试一点通:http://www.msedt.com/infoflow/details/1093

在开发过程中，经常会碰到一些业务场景，需要以完全模糊匹配的方式查找数据，就会想到用like %xxx% 或者 like %xxx的方式去实现，而且即使列上有选择率很高的索引，也不会被使用。在MySQL中可以通过ICP特性，全文索引，基于生成列索引解决这类问题，下面就从索引条件下推ICP，全文索引，基于生成列索引及如何利用它们解决模糊匹配的SQL性能问题。

索引条件下推ICP

ICP介绍

MySQL 5.6开始支持ICP（Index Condition Pushdown），不支持ICP之前，当进行索引查询时，首先根据索引来查找数据，然后再根据where条件来过滤，扫描了大量不必要的数据，增加了数据库IO操作。在支持ICP后，MySQL在取出索引数据的同时，判断是否可以进行where条件过滤，将where的部分过滤操作放在存储引擎层提前过滤掉不必要的数据，减少了不必要数据被扫描带来的IO开销。在某些查询下，可以减少Server层对存储引擎层数据的读取，从而提供数据库的整体性能。

ICP具有以下特点



ICP相关控制参数

index_condition_pushdown：索引条件下推默认开启，设置为off关闭ICP特性。

mysql>show variables like 'optimizer_switch';
| optimizer_switch | index_condition_pushdown=on
# 开启或者关闭ICP特性
mysql>set optimizer_switch = 'index_condition_pushdown=on | off';复制代码

ICP处理过程

假设有用户表users01(id, name, nickname, phone, create_time)，表中数据有11W。由于ICP只能用于二级索引，故在name,nickname列上创建复合索引idx_name_nickname(name,nickname)，分析SQL语句**select * from users01 where name = 'Lyn' and nickname like '%SK%'**在ICP关闭和开启下的执行情况。

关闭ICP特性的SQL性能分析



开启profiling进行跟踪SQL执行期间每个阶段的资源使用情况。

mysql>set profiling  = 1;复制代码

关闭ICP特性分析SQL执行情况

mysql>set optimizer_switch = 'index_condition_pushdown=off';复制代码

mysql>explain select * from users01 where name = 'Lyn' and nickname like '%SK%';
|  1 | SIMPLE      | users01 | NULL       | ref  | idx_name_nickname | idx_name_nickname | 82      | const | 29016 |   100.00 | Using where |
#查看SQL执行期间各阶段的资源使用
mysql>show profile cpu,block io for query 2;
| Status                         | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+--------------------------------+----------+----------+------------+--------------+---------------+
| starting                       | 0.000065 | 0.000057 |   0.000009 |            0 |             0 |
..................
| executing                      | 0.035773 | 0.034644 |   0.000942 |            0 |             0 |#执行阶段耗时0.035773秒。
| end                            | 0.000015 | 0.000006 |   0.000009 |            0 |             0 |
#status状态变量分析
| Handler_read_next | 16384          |  ##请求读的行数
| Innodb_data_reads | 2989           |  #数据物理读的总数
| Innodb_pages_read | 2836           |  #逻辑读的总数
| Last_query_cost   | 8580.324460    |  #SQL语句的成本COST，主要包括IO_COST和CPU_COST。复制代码

通过explain分析执行计划，SQL语句在关闭CP特性的情况下，走的是复合索引idx_name_nickname，Extra=Using Where，首先通过复合索引idx_name_nickname前缀从存储引擎中读出name = 'Lyn'的所有记录，然后在Server端用where过滤nickname like '%SK%'情况。

Handler_read_next=16384说明扫描了16384行的数据，SQL实际返回只有12行数，耗时50ms。对于这种扫描大量数据行，只返回少量数据的SQL，可以从两个方面去分析。


	
**索引选择率低：**对于符合索引（name,nickname)，name作为前导列出现where条件，CBO都会选择走索引，因为扫描索引比全表扫描的COST要小，但由于name列的基数不高，导致扫描了索引中大量的数据，导致SQL性能也不太高。

	
Column_name: name Cardinality: 6可以看到users01表中name的不同的值只有6个，选择率6/114688很低。
	
	

	
**数据分布不均匀：**对于where name = ?来说，name数据分布不均匀时，SQL第一次传入的值返回结果集很小，CBO就会选择走索引，同时将SQL的执行计划缓存起来，以后不管name传入任何值都会走索引扫描，这其实是不对的，如果传入name的值是Fly100返回表中80%的数据，这是走全表扫描更快。
	
| name      | count(*) |
+---------------+----------+
| Grubby        |    12    |
| Lyn           |    1000  |
| Fly100        |    98100 |复制代码

在MySQL 8.0推出了列的直方图统计信息特性，主要针对索引列数据分布不均匀的情况进行优化。

开启ICP特性的性能分析



开启ICP特性分析SQL执行情况

mysql>set optimizer_switch = 'index_condition_pushdown=on';复制代码

#执行计划
|  1 | SIMPLE      | users01 | NULL       | ref  | idx_name_nickname | idx_name_nickname | 82      | const | 29016 |    11.11 | Using index condition |
#status状态变量分析
| Handler_read_next | 12             |
| Innodb_data_reads | 2989           |
| Innodb_pages_read | 2836           |
| Last_query_cost   | 8580.324460    |复制代码

从执行计划可以看出，走了复合索引idx_name_nickname，Extra=Using index condition，且只扫描了12行数据，说明使用了索引条件下推ICP特性，SQL总共耗时10ms，跟关闭ICP特性下相比，SQL性能提升了5倍。

ICP特性/项目
			
扫描方式
			
扫描行数
			
返回行数
			
执行时间
		
关闭ICP
			
Using where
			
16384
			
12
			
50ms
		
开启ICP
			
Using index condition
			
12
			
12
			
10ms
		
开启ICP特性后，由于nickname的like条件可以通过索引筛选，存储引擎层通过索引与where条件的比较来去除不符合条件的记录，这个过程不需要读取记录，同时只返回给Server层筛选后的记录，减少不必要的IO开销。

Extra显示的索引扫描方式

**using where：**查询使用索引的情况下，需要回表去查询所需的数据。
	
**using index condition：**查询使用了索引，但是需要回表查询数据。
	
**using index ：**查询使用覆盖索引的时候会出现。
	
**using index & using where：**查询使用了索引，但是需要的数据都在索引列中能找到，不需要回表查询数据。
模糊匹配改写优化

在开启ICP特性后，对于条件**where name = 'Lyn' and nickname like '%SK%'**可以利用复合索引(name,nickname)减少不必要的数据扫描，提升SQL性能。但对于where nickname like '%SK%'完全模糊匹配查询能否利用ICP特性提升性能？首先创建nickname上单列索引idx_nickname。

mysql>alter table users01 add index idx_nickname(nickname);
#SQL执行计划
|  1 | SIMPLE      | users01 | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 114543 |    11.11 | Using where |复制代码

从执行计划看到type=ALL，Extra=Using where走的是全部扫描，没有利用到ICP特性。

辅助索引idx_nickname(nickname)内部是包含主键id的，等价于(id，nickname)的复合索引，尝试利用覆盖索引特性将SQL改写为select Id from users01 where nickname like '%SK%'**。

|  1 | SIMPLE      | users01 | NULL       | index | NULL          | idx_nickname | 83      | NULL | 114543 |    11.11 | Using where; Using index |复制代码

从执行计划看到，type=index，Extra=Using where; Using index，索引全扫描，但是需要的数据都在索引列中能找到，不需要回表。利用这个特点，将原始的SQL语句先获取主键id，然后通过id跟原表进行关联，分析其执行计划。

select  * from users01 a , (select id from users01 where nickname like '%SK%') b where a.id = b.id;复制代码

|  1 | SIMPLE      | users01 | NULL       | index  | PRIMARY       | idx_nickname | 83      | NULL            | 114543 |    11.11 | Using where; Using index |
|  1 | SIMPLE      | a       | NULL       | eq_ref | PRIMARY       | PRIMARY      | 4       | test.users01.id |      1 |   100.00 | NULL                     |复制代码

从执行计划看，走了索引idx_nickname，不需要回表访问数据，执行时间从60ms降低为40ms，type = index 说明没有用到ICP特性，但是可以利用Using where; Using index这种索引扫描不回表的方式减少资源开销来提升性能。

全文索引

MySQL 5.6开始支持全文索引，可以在变长的字符串类型上创建全文索引，来加速模糊匹配业务场景的DML操作。它是一个inverted index（反向索引），创建fulltext index时会自动创建6个auxiliary index tables（辅助索引表），同时支持索引并行创建，并行度可以通过参数innodb_ft_sort_pll_degree设置，对于大表可以适当增加该参数值。

删除全文索引的表的数据时，会导致辅助索引表大量delete操作，InnoDB内部采用标记删除，将已删除的DOC_ID都记录特殊的FTS_*_DELETED表中，但索引的大小不会减少，需要通过设置参数innodb_optimize_fulltext_only=ON后，然后运行OPTIMIZE TABLE来重建全文索引。

全文索引特征


	
从MySQL 5.7开始内置了ngram全文检索插件，用来支持中文分词，并且对MyISAM和InnoDB引擎有效。
	
	

	
由于全文索引的缓存和批量处理的特性，Insert&Update操作是在事务提交时处理，只能看到提交后的数据。
	
	

	
全文索引使用函数MATCH() ….. AGAINST()来进行检索，MATCH()中列个数及顺序必须和索引定义保持一致。
	
	

	
只能用于InnoDB和MyISAM的表，不支持分区表，不支持%通配符搜索。
	
	

	
MATCH()列表与表的全文索引定义列完全匹配。
	
	

	
MySQL优化器Hint对于全文索引会被限制。
	
两种检索模式


	
IN NATURAL LANGUAGE MODE：默认模式，以自然语言的方式搜索，AGAINST('看风' IN NATURAL LANGUAGE MODE ) 等价于AGAINST('看风'）。
	
	

	
**IN BOOLEAN MODE：**布尔模式，表是字符串前后的字符有特殊含义，如查找包含SK，但不包含Lyn的记录，可以用+，-符号。

	
AGAINST('+SK -Lyn' in BOOLEAN MODE);
	


这时查找nickname like '%Lyn%'，通过反向索引关联数组可以知道，单词Lyn存储于文档4中，然后定位到具体的辅助索引表中。

全文索引分析

对表users01的nickname添加支持中文分词的全文索引

mysql>alter table users01 add fulltext index idx_full_nickname(nickname) with parser ngram;复制代码

查看数据分布

#设置当前的全文索引表
mysql>set global innodb_ft_aux_table = 'test/users01';
#查看数据文件
mysql>select * from information_schema.innodb_ft_index_cache;
+--------+--------------+-------------+-----------+--------+----------+
| WORD   | FIRST_DOC_ID | LAST_DOC_ID | DOC_COUNT | DOC_ID | POSITION |
+--------+--------------+-------------+-----------+--------+----------+
.............
| 看风   |            7 |           7 |         1 |      7 |        3 |
| 笑看   |            7 |           7 |         1 |      7 |        0 |复制代码

全文索引相关对象分析

#全文索引对象分析
mysql>SELECT table_id, name, space from INFORMATION_SCHEMA.INNODB_TABLES where name like 'test/%';
|     1198 | test/users01                                       |   139 |
#存储被标记删除同时从索引中清理的文档ID,其中_being_deleted_cache是_being_deleted表的内存版本。
|     1199 | test/fts_00000000000004ae_being_deleted            |   140 |
|     1200 | test/fts_00000000000004ae_being_deleted_cache      |   141 |
#存储索引内部状态信息及FTS_SYNCED_DOC_ID
|     1201 | test/fts_00000000000004ae_config                   |   142 | 
#存储被标记删除但没有从索引中清理的文档ID,其中_deleted_cache是_deleted表的内存版本。
|     1202 | test/fts_00000000000004ae_deleted                  |   143 |
|     1203 | test/fts_00000000000004ae_deleted_cache            |   144 |复制代码

模糊匹配优化

对于SQL语句后面的条件nickname like '%看风%'默认情况下，CBO是不会选择走nickname索引的，该写SQL为全文索引匹配的方式：match(nickname) against('看风')。

mysql>explain select * from users01 where match(nickname) against('看风');
|  1 | SIMPLE      | users01 | NULL       | fulltext | idx_full_nickname | idx_full_nickname | 0       | const |    1 |   100.00 | Using where; Ft_hints: sorted |复制代码

使用了全文索引的方式查询，type=fulltext，同时命中全文索引idx_full_nickname，从上面的分析可知，在MySQL中，对于完全模糊匹配%%查询的SQL可以通过全文索引提高效率。

生成列

MySQL 5.7开始支持生成列，生成列是由表达式的值计算而来，有两种模式：VIRTUAL和STORED，如果不指定默认是VIRTUAL，创建语法如下：

col_name data_type [GENERATED ALWAYS] AS (expr)  [**VIRTUAL** | **STORED**] [NOT NULL | NULL]复制代码



生成列特征

VIRTUAL生成列用于复杂的条件定义，能够简化和统一查询，不占用空间，访问列是会做计算。
	
STORED生成列用作物化缓存，对于复杂的条件，可以降低计算成本，占用磁盘空间。
	
支持辅助索引的创建，分区以及生成列可以模拟函数索引。
	
不支持存储过程，用户自定义函数的表达式，NONDETERMINISTIC的内置函数，如NOW()， RAND()以及不支持子查询
生成列使用

#添加基于函数reverse的生成列reverse_nickname
mysql>alter table users01 add reverse_nickname varchar(200) generated always as (reverse(nickname));
#查看生成列信息
mysql>show columns from users01;
| reverse_nickname | varchar(200) | YES  |     | NULL              | VIRTUAL GENERATED | #虚拟生成列复制代码

模糊匹配优化

对于where条件后的like '%xxx'是无法利用索引扫描，可以利用MySQL 5.7的生成列模拟函数索引的方式解决，具体步骤如下：

利用内置reverse函数将like '%风云'反转为like '云风%'，基于此函数添加虚拟生成列。
	
在虚拟生成列上创建索引。
	
将SQL改写成通过生成列like reverse('%风云')去过滤，走生成列上的索引。
添加虚拟生成列并创建索引。

mysql>alter table users01 add reverse_nickname varchar(200) generated always as (reverse(nickname));
mysql>alter table users01 add index idx_reverse_nickname(reverse_nickname);
#SQL执行计划
|  1 | SIMPLE      | users01 | NULL       | range | idx_reverse_nickname | idx_reverse_nickname | 803     | NULL |    1 |   100.00 | Using where |复制代码

可以看到对于like '%xxx'无法使用索引的场景，可以通过基于生成列的索引方式解决。

总结

 

介绍了索引条件下推ICP特性，全文索引以以及生成列特性，利用这些特性可以对模糊匹配like %xxx%或like %xxx的业务SQL进行优化，可以有效降低不必要的数据读取，减少IO扫描以及CPU开销，提高服务的稳定性。对于MySQL每个版本发布的新特性，尤其是跟优化器和SQL相关的，应该去关注和了解，可能会发现适合自己业务场景的特性。

    
在SQL查询中，为了提高查询的效率，我们常常采取一些措施对查询语句进行SQL性能优化。本文我们总结了一些优化措施，接下来我们就一一介绍。
1.查询的模糊匹配
尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 百分号会导致相关列的索引无法使用，最好不要用。
解决办法:
其实只需要对该脚本略做改进，查询速度便会提高近百倍。改进方法如下：
a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表，用户模糊输入供应商名称时，直接在前台就帮忙定位到具体的供应商，这样在调用后台程序时，这列就可以直接用等于来关联了。
b、直接修改后台——根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里头，然后再用临时表去做复杂关联。
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语句来完成（前些时候在协助xxx项目做性能问题分析时就发现存在这种情况）
5.在可以使用UNION ALL的语句里，使用了UNION
UNION 因为会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。一般来说，如果使用UNION ALL能满足要求的话，务必使用UNION ALL。还有一种情况大家可能会忽略掉，就是虽然要求几个子集的并集需要过滤掉重复记录，但由于脚本的特殊性，不可能存在重复记录，这时便应该使用 UNION ALL，如xx模块的某个查询程序就曾经存在这种情况，见，由于语句的特殊性，在这个脚本中几个子集的记录绝对不可能重复，故可以改用UNION ALL）。
6.在WHERE 语句中，尽量避免对索引字段进行计算操作
这个常识相信绝大部分开发人员都应该知道，但仍有不少人这么使用，我想其中一个最主要的原因可能是为了编写写简单而损害了性能，那就不可取了。9月份在对XX系统做性能分析时发现，有大量的后台程序存在类似用法，如：where trunc(create_date)=trunc(:date1)，虽然已对create_date 字段建了索引，但由于加了TRUNC，使得索引无法用上。此处正确的写法应该是where create_date>=trunc(:date1) and create_date< pre=""><>或者是where create_date between trunc(:date1) and trunc(:date1)+1-1/(24*60*60)。
注意：因between 的范围是个闭区间（greater than or equal to low value and less than or equal to high value.），故严格意义上应该再减去一个趋于0的小数，这里暂且设置成减去1秒（1/(24*60*60)），如果不要求这么精确的话，可以略掉这步。
7.对Where 语句的法则
7.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) 

7.2 不要以字符格式声明数字，要以数字格式声明字符值。（日期同样）否则会使索引无效，产生全表扫描。
例子使用：
SELECT emp.ename, emp.job FROM emp WHERE emp.empno = 7369;
--不要使用：
SELECT emp.ename, emp.job FROM emp WHERE emp.empno = '7369'
8.对Select语句的法则
在应用程序、包和过程中限制使用select * from table这种方式。看下面例子
--使用
SELECT empno,ename,category FROM emp WHERE empno = '7369'
--而不要使用
SELECT * FROM emp WHERE empno = '7369'
9. 排序
避免使用耗费资源的操作，带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎 执行，耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序。
10.临时表
慎重使用临时表可以极大的提高系统性能。
关于SQL性能优化的知识就介绍到这里了，希望本次的介绍能够带给您一些收获，谢谢！

转载于:https://www.cnblogs.com/huizi0314/p/6635236.html

          

SQL查询优化：如何写出高性能SQL语句
1.查询的模糊匹配
尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用，最好不要用.
解决办法:
其实只需要对该脚本略做改进，查询速度便会提高近百倍。改进方法如下：
a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表，用户模糊输入供应商名称时，直接在前台就帮忙定位到具体的供应商，这样在调用后台程序时，这列就可以直接用等于来关联了。
b、直接修改后台——根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里头，然后再用临时表去做复杂关联
2.索引问题
在
做性能跟踪分析过程中，经常发现有不少后台程序的性能问题是因为缺少合适索引造成的，有些表甚至一个索引都没有。这种情况往往都是因为在设计表时，没去定
义索引，而开发初期，由于表记录很少，索引创建与否，可能对性能没啥影响，开发人员因此也未多加重视。然一旦程序发布到生产环境，随着时间的推移，表记录越来越多
这时缺少索引，对性能的影响便会越来越大了。
这个问题需要数据库设计人员和开发人员共同关注
法则：不要在建立的索引的数据列上进行下列操作:
◆避免对索引字段进行计算操作
◆避免在索引字段上使用not，<>，!=
◆避免在索引列上使用IS NULL和IS NOT NULL
◆避免在索引列上出现数据类型转换
◆避免在索引字段上使用函数
◆避免建立索引的列中使用空值。
3.复杂操作
部分UPDATE、SELECT 语句 写得很复杂（经常嵌套多级子查询）——可以考虑适当拆成几步，先生成一些临时数据表，再进行关联操作


				
转载于:https://blog.51cto.com/xuliangjun/1755151

在SQL查询中，为了提高查询的效率，我们常常采取一些措施对查询语句进行SQL性能优化。本文我们总结了一些优化措施，接下来我们就一一介绍。
1.查询的模糊匹配
尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用，最好不要用。
解决办法:
其实只需要对该脚本略做改进，查询速度便会提高近百倍。改进方法如下：
a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表，用户模糊输入供应商名称时，直接在前台就帮忙定位到具体的供应商，这样在调用后台程序时，这列就可以直接用等于来关联了。
b、直接修改后台——根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里头，然后再用临时表去做复杂关联。
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语句来完成（前些时候在协助xxx项目做性能问题分析时就发现存在这种情况）
5.在可以使用UNION ALL的语句里，使用了UNION
UNION 因为会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。一般来说，如果使用UNION ALL能满足要求的话，务必使用UNION ALL。还有一种情况大家可能会忽略掉，就是虽然要求几个子集的并集需要过滤掉重复记录，但由于脚本的特殊性，不可能存在重复记录，这时便应该使用 UNION ALL，如xx模块的某个查询程序就曾经存在这种情况，见，由于语句的特殊性，在这个脚本中几个子集的记录绝对不可能重复，故可以改用UNION ALL）。
6.在WHERE 语句中，尽量避免对索引字段进行计算操作
这个常识相信绝大部分开发人员都应该知道，但仍有不少人这么使用，我想其中一个最主要的原因可能是为了编写写简单而损害了性能，那就不可取了。9月份在对XX系统做性能分析时发现，有大量的后台程序存在类似用法，如：where trunc(create_date)=trunc(:date1)，虽然已对create_date 字段建了索引，但由于加了TRUNC，使得索引无法用上。此处正确的写法应该是where create_date>=trunc(:date1) and create_date< pre=""><>或者是where create_date between trunc(:date1) and trunc(:date1)+1-1/(24*60*60)。
注意：因between 的范围是个闭区间（greater than or equal to low value and less than or equal to high value.），故严格意义上应该再减去一个趋于0的小数，这里暂且设置成减去1秒（1/(24*60*60)），如果不要求这么精确的话，可以略掉这步。
7.对Where 语句的法则
7.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) 

7.2 不要以字符格式声明数字，要以数字格式声明字符值。（日期同样）否则会使索引无效，产生全表扫描。
例子使用：
SELECT emp.ename, emp.job FROM emp WHERE emp.empno = 7369;
--不要使用：
SELECT emp.ename, emp.job FROM emp WHERE emp.empno = '7369'
8.对Select语句的法则
在应用程序、包和过程中限制使用select * from table这种方式。看下面例子
--使用
SELECT empno,ename,category FROM emp WHERE empno = '7369'
--而不要使用
SELECT * FROM emp WHERE empno = '7369'
9. 排序
避免使用耗费资源的操作，带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎 执行，耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序。
10.临时表
慎重使用临时表可以极大的提高系统性能。
关于SQL性能优化的知识就介绍到这里了，希望本次的介绍能够带给您一些收获，谢谢！