人们在使用sql时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。笔者在工作实践中发现，不良的sql往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。
在对它们进行适当的优化后，其运行速度有了明显地提高！
测试环境:主机：HP LH II----主频：330MHZ----内存：128兆----
操作系统：Operserver5.0.4----
数据库：Sybase11.0.3
一、不合理的索引设计----
---- 1.在date上建有一非个群集索引
'19991201' and date < '19991214'and amount >2000 (25秒)
'19990901' and place in ('BJ','SH') (27秒)
----分析：----
---- 2.在date上的一个群集索引
'19991201' and date < '19991214' and amount >2000（14秒）
'19990901' and place in ('BJ','SH')（14秒）
---- 3.在place，date，amount上的组合索引
'19991201' and date < '19991214' and amount >2000（26秒）
'19990901' and place in ('BJ,'SH')（< 1秒）
----分析：----这是一个不很合理的组合索引，因为它的前导列是place，第一和第二条sql没有引用place，因此也没有利用上索引；第三个sql使用了place，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。
---- 4.在date，place，amount上的组合索引
'19991201' and date < '19991214' and amount >2000(< 1秒)
'19990901' and place in ('BJ','SH')（< 1秒）
一般来说：
②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；
二、不充份的连接条件：
外层表account上的22541页+（外层表account的191122行*内层表card上对应外层表第一行所要查找的3页）=595907次I/O
在第二个连接条件下，最佳查询方案是将card作外层表，account作内层表，利用account上的索引，其I/O次数可由以下公式估算为：外层表card上的1944页+（外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O
可见，只有充份的连接条件，真正的最佳方案才会被执行。
1.多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。
三、不可优化的where子句
分析：
分析：---- where条件中的'in'在逻辑上相当于'or'，所以语法分析器会将in ('0','1')转化为id_no ='0' or id_no='1'来执行。
我们期望它会根据每个or子句分别查找，再将结果相加，这样可以利用id_no上的索引；
但实际上（根据showplan）,它却采用了"OR策略"，即先取出满足每个or子句的行，存入临时数据库的工作表中，再建立唯一索引以去掉重复行，最后从这个临时表中计算结果。因此，实际过程没有利用id_no上索引，并且完成时间还要受tempdb数据库性能的影响。
得到两个结果，再作一次加法合算。因为每句都使用了索引，执行时间只有3秒，在620000行下，时间也只有4秒。
直接算出结果，执行时间同上面一样快！
可见，所谓优化即where子句利用了索引，不可优化即发生了表扫描或额外开销。
2.in、or子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把子句拆开；拆开的子句中应该包含索引。
从以上这些例子可以看出，sql优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实sql的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。
=”，不要使用“>”。viii. 注意一些or子句和union子句之间的替换ix. 注意表之间连接的数据类型，避免不同类型数据之间的连接。x. 注意存储过程中参数和数据类型的关系。xi. 注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过200个数据页面（400k），那么系统将会进行锁升级，页级锁会升级成表级锁。b) 索引的使用规范：i. 索引的创建要与应用结合考虑，建议大的OLTP表不要超过6个索引。ii. 尽可能的使用索引字段作为查询条件，尤其是聚簇索引，必要时可以通过index index_name来强制指定索引iii. 避免对大表查询时进行table scan，必要时考虑新建索引。iv. 在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。v. 要注意索引的维护，周期性重建索引，重新编译存储过程。c) tempdb的使用规范：i. 尽量避免使用distinct、order by、group by、having、join、***pute，因为这些语句会加重tempdb的负担。ii. 避免频繁创建和删除临时表，减少系统表资源的消耗。iii. 在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度；如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。iv. 如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。v. 如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。vi. 慎用大的临时表与其他大表的连接查询和修改，减低系统表负担，因为这种操作会在一条语句中多次使用tempdb的系统表。d) 合理的算法使用：
