1. sql语句性能如何优化
SQL语句的优化是将性能低下的SQL语句转换成目的相同的性能优异的SQL语句。
人工智能自动SQL优化就是使用人工智能技术，自动对SQL语句进行重写，从而找到性能最好的等效SQL语句。
数据库性能的优化
一个数据库系统的生命周期可以分成：设计、开发和成品三个阶段。在设计阶段进行数据库性能优化的成本最低，收益最大。在成品阶段进行数据库性能优化的成本最高，收益最小。
数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。最常见的优化手段就是对硬件的升级。根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升，全部加起来只占数据库系统性能提升的40%左右，其余的60%系统性能提升来自对应用程序的优化。许多优化专家认为，对应用程序的优化可以得到80%的系统性能的提升。
应用程序的优化
应用程序的优化通常可分为两个方面：源代码和SQL语句。由于涉及到对程序逻辑的改变，源代码的优化在时间成本和风险上代价很高，而对数据库系统性能的提升收效有限。
为什么要优化SQL语句
. SQL语句是对数据库进行操作的惟一途径，对数据库系统的性能起着决定性的作用。
. SQL语句消耗了70%至90%的数据库资源。
. SQL语句独立于程序设计逻辑，对SQL语句进行优化不会影响程序逻辑。
. SQL语句有不同的写法，在性能上的差异非常大。
. SQL语句易学，但难精通。
优化SQL语句的传统方法是通过手工重写来对SQL语句进行优化。DBA或资深程序员通过对SQL语句执行计划的分析，依靠经验，尝试重写SQL语句，然后对结果和性能进行比较，以试图找到性能较佳的SQL语句。这种传统上的作法无法找出SQL语句的所有可能写法，且依赖于人的经验，非常耗费时间。
SQL优化技术的发展历程
第一代SQL优化工具是执行计划分析工具。这类工具针对输入的SQL语句，从数据库提取执行计划，并解释执行计划中关键字的含义。
第二代SQL优化工具只能提供增加索引的建议，它通过对输入的SQL语句的执行计划的分析，来产生是否要增加索引的建议。
第三代SQL优化工具不仅分析输入SQL语句的执行计划，还对输入的SQL语句本身进行语法分析，经过分析产生写法上的改进建议。
人工智能自动SQL优化
图1 人工智能自动SQL优化示意图
人工智能自动SQL优化出现在90年代末。目前在商用数据库领域，LECCO Technology Limited(灵高科研有限公司)拥有该技术，并提供使用该技术的自动优化产品LECCO SQL Expert，它支持Oracle、Sybase、MS SQL Server和IBM DB2数据库平台。该产品针对数据库应用的开发和维护阶段提供的模块有：SQL语法优化器、PL/SQL集成化开发调试环境(IDE)、扫描器、数据库监视器等。其核心模块SQL 语法优化器的工作原理为：①输入一条源SQL语句；②“人工智能反馈式搜索引擎”对输入的SQL语句，结合检测到的数据库结构和索引进行重写，产生N条等效的SQL语句输出；③产生的N条等效SQL语句再送入“人工智能反馈式搜索引擎”进行重写，直至无法产生新的输出或搜索限额满；④对输出的SQL语句进行过滤，选出具有不同执行计划的SQL语句；⑤对得到的SQL语句进行批量测试，找出性能最好的SQL语句。
LECCO SQL Expert自动优化实例
假设我们从源代码中抽取出这条SQL语句(也可以通过内带的扫描器或监视器获得SQL语句)：
SELECT COUNT(*)
FROM EMPLOYEE
swheresEXISTS (SELECT 'X'
FROM DEPARTMENT
swheresEMP_DEPT=DPT_ID
AND DPT_NAME LIKE 'AC%')
AND EMP_ID IN (SELECT SAL_EMP_ID
FROM EMP_SAL_HIST B
swheresSAL_SALARY ＞ 70000)
按下“优化”按钮后，经过10几秒，SQL Expert就完成了优化的过程，并在这10几秒的时间里重写产生了2267 条等价的SQL语句，其中136条SQL语句有不同的执行计划。
接下来，我们可以对自动重写产生的136条SQL语句进行批运行测试，以选出性能最佳的等效SQL语句。按下“批运行” 按钮，在“终止条件” 页选择“最佳运行时间SQL语句”，按“确定”。
经过几分钟的测试运行后，我们可以发现SQL124的运行时间和反应时间最短。运行速度约有22.75倍的提升(源SQL语句运行时间为2.73秒，SQL124运行时间为0.12秒)。现在我们就可以把SQL124放入源代码中，结束一条SQL语句的优化工作了。
“边做边学式训练”提升SQL开发水平
LECCO SQL Expert不仅能够找到最佳的SQL语句，它所提供的“边做边学式训练”还能够教开发人员和数据库管理员如何写出性能最好的SQL语句。LECCO SQL Expert的“SQL比较器”可以标明源SQL和待选SQL间的不同之处。
以上面优化的结果为例，为了查看源SQL语句和SQL124在写法上有什么不同，我们可以按下“比较器” 按钮，对SQL124和源SQL语句进行比较。“SQL 比较器”将SQL124相对于源SQL语句的不同之处以蓝颜色表示了出来。如果选择“双向比较”复选框，“SQL 比较器”可以将两条SQL语句的不同之处以蓝色表示。当然，我们也可以从源语句和重写后的SQL 语句中任选两条进行比较。
从比较的结果可以看到，重写后的SQL124把第一个Exists改写成了In；在字段DPT_ID上进行了合并空字符串的操作，以诱导数据库先执行子查询中的
(SELECT DPT_ID||''
FROM DEPARTMENT
WHERE DPT_NAME LIKE 'AC%')
在子查询完成后，再与EMPLOYEE表进行嵌套循环连接(Nested Loop Join)。
如果觉得对写法的改变难以理解，还可以点中“执行计划”复选框，通过比较两条SQL语句的执行计划的不同，来了解其中的差异。在查看执行计划过程中，如果有什么不明白的地方，可以点中“SQL信息按钮”，再点击执行计划看不明白的地方，LECCO SQL Expert的上下文敏感帮助系统将提供执行计划该处的解释。
在“SQL比较器”中，选中“统计信息”复选框后，可得到详细的两条SQL语句运行时的统计信息比较，这对于学习不同的SQL写法对数据库资源的消耗很有帮助。
LECCO SQL Expert优化模块的特点
LECCO SQL Expert优化模块的特点主要表现为：自动优化SQL语句；以独家的人工智能知识库“反馈式搜索引擎”来重写性能优异的SQL语句；找出所有等效的SQL语句及可能的执行计划；保证产生相同的结果；先进的SQL语法分析器能处理最复杂的SQL语句；可以重写SELECT、SELECT INTO、UPDATE、INSERT和DELETE语句；通过测试运行，为应用程序和数据库自动找到性能最好的SQL语句；提供微秒级的计时，能够优化Web应用程序和有大量用户的在线事务处理中运行时间很短的SQL语句；为开发人员提供“边做边学式训练”，迅速提高开发人员的SQL编程技能；提供上下文敏感的执行计划帮助系统和SQL运行状态帮助；不是猜测或建议，而是独一无二的SQL重写解决方案。
写出专家级的SQL语句
LECCO SQL Expert的出现，使SQL的优化变得极其简单，只要能够写出SQL语句，它就能帮用户找到最好性能的写法。LECCO SQL Expert不仅能在很短的时间内找到所有可能的优化方案，而且能够通过实际测试，确定最有效的优化方案。同以往的数据库优化手段相比较，LECCO SQL Expert将数据库优化技术带到了一个崭新的技术高度，依赖人的经验、耗费大量时间、受人的思维束缚的数据库优化手段已经被高效、省时且准确的自动优化软件所取代了。通过内建的“LECCO小助手”的帮助，即使是SQL的开发新手，也能快速且简单地写出专家级的SQL语句。
2. 确定某种条件的数据存在，怎样写sql资源消耗最少
你的问题跟你的描述感觉不太对，如果是单纯的要确定A表是否含有B表的ID可以这样写：select * from A,B where a.id=b.id,如果你是想如果B表中新增一个ID时，A表的该ID数据不可删除那么你可以在A表增加一个字段INT（值为1或者0），写个触发器，当B表增加一个ID就判断下A表是否有该ID，如果有就将A表的INT字段改为1，这样如果删除时候再判断INT是否为1就可以了。
3. 请简单说明SQL语句书可以提高执行效率的5种需要注意的书写方法。
之前收集的一些资料仅供参考, 不一定完全正确... 有错误望指正
1、操作符号： NOT IN操作符
此操作是强列推荐不使用的，因为它不能应用表的索引。推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替 "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", "LIKE '%500'"，因为他们不走索引全是表扫描。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS、IN、LEFT OUTER JOIN来替代，特别是左连接,而Exists比IN更快，最慢的是NOT操作. 如果列的值含有空，以前它的索引不起作用，现在2000的优化器能够处理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能优化她，而"<>"等还是不能优化，用不到索引。
2、注意union和union all的区别。union比union all多做了一步distinct操作。能用union all的情况下尽量不用union。
3、查询时尽量不要返回不需要的行、列。另外在多表连接查询时，尽量改成连接查询，少用子查询。。
4、尽量少用视图，它的效率低。对视图操作比直接对表操作慢,可以用存储过程来代替它。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。
我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，
直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰.为了加快视图的查询，MsSQL增加了视图索引的功能。
5、创建合理的索引，对于插入或者修改比较频繁的表，尽量慎用索引。因为如果表中存在索引，插入和修改时也会引起全表扫描。
索引一般使用于where后经常用作条件的字段上。
6、在表中定义字段或者存储过程、函数中定义参数时，将参数的大小设置为合适即可，勿设置太大。这样开销很大。
7、Between在某些时候比IN速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。
select * from chineseresume where title in ('男','女')
Select * from chineseresume where between '男' and '女'是一样的。由于in会在比较多次，所以有时会慢些。
8、在必要是对全局或者局部临时表创建索引，有时能够提高速度，但不是一定会这样，因为索引也耗费大量的资源。他的创建同是实际表一样。
9、WHERE后面的条件顺序影响
WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响，如
Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以上两个SQL中dy_dj（电压等级）及xh_bz（销户标志）两个字段都没进行索引，所以执行的时候都是全表扫描，如果dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。所以尽量将范围小的条件放在前面。。
10、用OR的字句可以分解成多个查询，并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引，用 UNION all执行的效率更高.多个OR的字句没有用到索引，改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。
11、没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION和UNION ALL一样的道理。
12、使用in时，在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，这样可以减少判断的次数
13、当用SELECT INTO时，它会锁住系统表(sysobjects，sysindexes等等)，阻塞其他的连接的存取。创建临时表时用显示声明语句，在另一个连接中SELECT * from sysobjects可以看到 SELECT INTO 会锁住系统表， Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事物内使用它！！！这样的话如果是经常要用的临时表请使用实表，或者临时表变量。
14、一般在GROUP BY和HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：select 的Where字句选择所有合适的行，Group By用来分组个统计行，Having字句用来剔除多余的分组。这样Group By和Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算，只是分组，那么用Distinct更快
15、一次更新多条记录比分多次更新每次一条快,就是说批处理好
16、慎用临时表，临时表存储于tempdb库中，操作临时表时，会引起跨库操作。尽量用结果集和表变量来代替它。
17、尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过，并且被组织到一个执行规划里、且存储在数据库中的 SQL语句，是控制流语言的集合，速度当然快。
18、不要在一段SQL或者存储过程中多次使用相同的函数或相同的查询语句，这样比较浪费资源,建议将结果放在变量里再调用。这样更快。
19、按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你（不经意的）某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁很难被发现
4. 如何写有效率的SQL查询
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在where及orderby涉及的列上建立索引。
2.应尽量避免在where子句中对字段进行null值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
selectidfromtwherenumisnull
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
selectidfromtwherenum=0
3.应尽量避免在where子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在where子句中使用or来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
selectidfromtwherenum=10ornum=20
可以这样查询：
selectidfromtwherenum=10
unionall
selectidfromtwherenum=20
5.in和notin也要慎用，否则会导致全表扫描，如：
selectidfromtwherenumin(1,2,3)
对于连续的数值，能用between就不要用in了：
6.下面的查询也将导致全表扫描：
selectidfromtwherenamelike'%abc%'
若要提高效率，可以考虑全文检索。
7.如果在where子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
selectidfromtwherenum=@num
可以改为强制查询使用索引：
selectidfromtwith(index(索引名))wherenum=@num
8.应尽量避免在where子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
selectidfromtwherenum/2=100
应改为:
selectidfromtwherenum=100*2
9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
selectidfromtwheresubstring(name,1,3)='abc'--name以abc开头的id
selectidfromtwheredatediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
应改为:
selectidfromtwherenamelike'abc%'
selectidfromtwherecreatedate>='2005-11-30'andcreatedate<'2005-12-1'
10.不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
12.不要写一些没有意义的查询，如需要生成一个空表结构：
selectcol1,col2into#tfromtwhere1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
createtable#t(...)
13.很多时候用exists代替in是一个好的选择：
selectnumfromawherenumin(selectnumfromb)
用下面的语句替换：
selectnumfromawhereexists(select1frombwherenum=a.num)
14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15.索引并不是越多越好，索引固然可以提高相应的select的效率，但同时也降低了insert及update的效率，因为insert或update时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16.应尽可能的避免更新clustered索引数据列，因为clustered索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新clustered索引数据列，那么需要考虑是否应将该索引建为clustered索引。
17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18.尽可能的使用varchar/nvarchar代替char/nchar，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19.任何地方都不要使用select*fromt，用具体的字段列表代替“*”，不要返回用不到的任何字段。
20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
21.避免频繁创建和删除临时表，以减少系统表资源的消耗。
22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
23.在新建临时表时，如果一次性插入数据量很大，那么可以使用selectinto代替createtable，避免造成大量log，以提高速度；如果数据量不大，为了缓和系统表的资源，应先createtable，然后insert。
24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncatetable，然后droptable，这样可以避免系统表的较长时间锁定。
25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27.与临时表一样，游标并不是不可使用。对小型数据集使用FAST_FORWARD游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28.在所有的存储过程和触发器的开始处设置SETNOCOUNTON，在结束时设置SETNOCOUNTOFF。无需在执行存储过程和触发器的每个语句后向客户端发送DONE_IN_PROC消息。
29.尽量避免大事务操作，提高系统并发能力。
30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理
5. 如何优化SQL语句
（1）选择最有效率的表名顺序(只在基于规则的优化器中有效)：
ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写
在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的
情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询
, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其
他表所引用的表.
（2） WHERE子句中的连接顺序．：
ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必
须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE
子句的末尾.
（3） SELECT子句中避免使用‘ * ‘：
ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过
查询数据字典完成的, 这意味着将耗费更多的时间
（4）减少访问数据库的次数：
ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变
量 , 读数据块等；
（5）在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加
每次数据库访问的检索数据量 ,建议值为200
（6）使用DECODE函数来减少处理时间：
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表.
（7）整合简单,无关联的数据库访问：
如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使
它们之间没有关系)
（8）删除重复记录：
最高效的删除重复记录方法 ( 因为使用了ROWID)例子：
DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)
FROM EMP X WHERE X.EMP_NO = E.EMP_NO);
（9）用TRUNCATE替代DELETE：
当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存
放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前
的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用TRUNCATE时, 回
滚段不再存放任何可被恢复的信息.当命令运行后,数据不能被恢复.因此很少的
资源被调用,执行时间也会很短. (译者按: TRUNCATE只在删除全表适
用,TRUNCATE是DDL不是DML)
（10）尽量多使用COMMIT：
只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求也
会因为COMMIT所释放的资源而减少:
COMMIT所释放的资源:
a. 回滚段上用于恢复数据的信息.
b. 被程序语句获得的锁
c. redo log buffer 中的空间
d. ORACLE为管理上述3种资源中的内部花费
（11）用Where子句替换HAVING子句：
避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行
过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,
那就能减少这方面的开销. (非oracle中)on、where、having这三个都可以加条
件的子句中，on是最先执行，where次之，having最后，因为on是先把不符合条
件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该
速度是最快的，where也应该比having快点的，因为它过滤数据后才进行sum，在
两个表联接时才用on的，所以在一个表的时候，就剩下where跟having比较了。
在这单表查询统计的情况下，如果要过滤的条件没有涉及到要计算字段，那它们
的结果是一样的，只是where可以使用rushmore技术，而having就不能，在速度
上后者要慢如果要涉及到计算的字段，就表示在没计算之前，这个字段的值是不
确定的，根据上篇写的工作流程，where的作用时间是在计算之前就完成的，而
having就是在计算后才起作用的，所以在这种情况下，两者的结果会不同。在多
表联接查询时，on比where更早起作用。系统首先根据各个表之间的联接条件，
把多个表合成一个临时表后，再由where进行过滤，然后再计算，计算完后再由
having进行过滤。由此可见，要想过滤条件起到正确的作用，首先要明白这个条
件应该在什么时候起作用，然后再决定放在那里
（12）减少对表的查询：
在含有子查询的SQL语句中,要特别注意减少对表的查询.例子：
SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECT
TAB_NAME,DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)
（13）通过内部函数提高SQL效率.：
复杂的SQL往往牺牲了执行效率. 能够掌握上面的运用函数解决问题的方法
在实际工作中是非常有意义的
（14）使用表的别名(Alias)：
当在SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每个Column
上.这样一来,就可以减少解析的时间并减少那些由Column歧义引起的语法错误.
（15）用EXISTS替代IN、用NOT EXISTS替代NOT IN：
在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行联
接.在这种情况下, 使用EXISTS(或NOT EXISTS)通常将提高查询的效率. 在子查
询中,NOT IN子句将执行一个内部的排序和合并. 无论在哪种情况下,NOT IN都是
最低效的 (因为它对子查询中的表执行了一个全表遍历). 为了避免使用NOT IN
,我们可以把它改写成外连接(Outer Joins)或NOT EXISTS.
例子：
（高效）SELECT * FROM EMP (基础表) WHERE EMPNO > 0 AND EXISTS (SELECT
‘X' FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = ‘MELB')
(低效)SELECT * FROM EMP (基础表) WHERE EMPNO > 0 AND DEPTNO IN(SELECT
DEPTNO FROM DEPT WHERE LOC = ‘MELB')
（16）识别'低效执行'的SQL语句：
虽然目前各种关于SQL优化的图形化工具层出不穷,但是写出自己的SQL工具
来解决问题始终是一个最好的方法：
SELECT EXECUTIONS , DISK_READS, BUFFER_GETS, ROUND((BUFFER_GETS-
DISK_READS)/BUFFER_GETS,2) Hit_radio, ROUND(DISK_READS/EXECUTIONS,2)
Reads_per_run,
SQL_TEXT FROM V$SQLAREA WHERE EXECUTIONS>0 AND BUFFER_GETS > 0 AND
(BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8 ORDER BY 4 DESC;
（17）用索引提高效率：
索引是表的一个概念部分,用来提高检索数据的效率，ORACLE使用了一个复
杂的自平衡B-tree结构. 通常,通过索引查询数据比全表扫描要快. 当ORACLE找
出执行查询和Update语句的最佳路径时, ORACLE优化器将使用索引. 同样在联结
多个表时使用索引也可以提高效率. 另一个使用索引的好处是,它提供了主键
(primary key)的唯一性验证.。那些LONG或LONG RAW数据类型, 你可以索引几乎
所有的列. 通常, 在大型表中使用索引特别有效. 当然,你也会发现, 在扫描小
表时,使用索引同样能提高效率. 虽然使用索引能得到查询效率的提高,但是我们
也必须注意到它的代价. 索引需要空间来存储,也需要定期维护, 每当有记录在
表中增减或索引列被修改时, 索引本身也会被修改. 这意味着每条记录的INSERT
, DELETE , UPDATE将为此多付出4 , 5 次的磁盘I/O . 因为索引需要额外的存
储空间和处理,那些不必要的索引反而会使查询反应时间变慢.。定期的重构索引
是有必要的.：
ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>
（18）用EXISTS替换DISTINCT：
当提交一个包含一对多表信息(比如部门表和雇员表)的查询时,避免在
SELECT子句中使用DISTINCT. 一般可以考虑用EXIST替换, EXISTS 使查询更为迅
速,因为RDBMS核心模块将在子查询的条件一旦满足后,立刻返回结果. 例子：
(低效): SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E
WHERE D.DEPT_NO = E.DEPT_NO (高效): SELECT DEPT_NO,DEPT_NAME FROM DEPT
D WHERE EXISTS ( SELECT ‘X' FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO);
（19） sql语句用大写的；因为oracle总是先解析sql语句，把小写的字母转换成大写的再执行
（20）在java代码中尽量少用连接符“＋”连接字符串！
21）避免在索引列上使用NOT 通常，
我们要避免在索引列上使用NOT, NOT会产生在和在索引列上使用函数相同的影响. 当ORACLE”遇到”NOT,他就会停止使用索引转而执行全表扫描.
（22）避免在索引列上使用计算．
WHERE子句中，如果索引列是函数的一部分．优化器将不使用索引而使用全表扫描．举例: 低效：- ·
- · SELECT ACCT_NUM, BALANCE_AMT FROM DEBIT_TRANSACTIONS
- WHERE TRAN_DATE ='31-DEC-95'UNIONSELECT ACCT_NUM, BALANCE_AMT
- FROM DEBIT_TRANSACTIONS WHERE TRAN_DATE ='31-DEC-95'高效: SELECT ACCT_NUM, BALANCE_AMT
- FROM DEBIT_TRANSACTIONS· WHERE TRAN_DATE ='31-DEC-95'UNIONALLSELECT ACCT_NUM, BALANCE_AMT
- FROM DEBIT_TRANSACTIONS WHERE TRAN_DATE ='31-DEC-95'·
- · SELECT JOB , AVG(SAL)
- · FROM EMP GROUP JOB HAVING JOB = ‘PRESIDENT' OR JOB = ‘MANAGER'高效:
- · SELECT JOB , AVG(SAL)
- · FROM EMP
- · WHERE JOB = ‘PRESIDENT'
- · OR JOB = ‘MANAGER'GROUP JOB
- ·
SELECT … FROM DEPT WHERE SAL *12>25000; 高效:
SELECT … FROM DEPT WHERE SAL >25000/12;
（23）用>=替代>
高效:
SELECT * FROM EMP WHERE DEPTNO >=4 低效:
SELECT * FROM EMP WHERE DEPTNO >3 两者的区别在于, 前者DBMS将直接跳到第一个DEPT等于4的记录而后者将首先定位到DEPTNO=3的记录并且向前扫描到第一个DEPT大于3的记录.
（24）用UNION替换OR (适用于索引列)
通常情况下, 用UNION替换WHERE子句中的OR将会起到较好的效果. 对索引列使用OR将造成全表扫描. 注意, 以上规则只针对多个索引列有效. 如果有column没有被索引, 查询效率可能会因为你没有选择OR而降低. 在下面的例子中, LOC_ID 和REGION上都建有索引. 高效: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 UNION SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE REGION = “MELBOURNE” 低效: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 OR REGION = “MELBOURNE” 如果你坚持要用OR, 那就需要返回记录最少的索引列写在最前面.
（25）用IN来替换OR
这是一条简单易记的规则，但是实际的执行效果还须检验，在ORACLE8i下，两者的执行路径似乎是相同的．
低效: SELECT…. FROM LOCATION WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30 高效 SELECT… FROM LOCATION WHERE LOC_IN IN (10,20,30);
（26）避免在索引列上使用IS NULL和IS NOT NULL
避免在索引中使用任何可以为空的列，ORACLE将无法使用该索引．对于单列索引，如果列包含空值，索引中将不存在此记录. 对于复合索引，如果每个列都为空，索引中同样不存在此记录.如果至少有一个列不为空，则记录存在于索引中．举例: 如果唯一性索引建立在表的A列和B列上, 并且表中存在一条记录的A,B值为(123,null) , ORACLE将不接受下一条具有相同A,B值（123,null）的记录(插入). 然而如果所有的索引列都为空，ORACLE将认为整个键值为空而空不等于空. 因此你可以插入1000 条具有相同键值的记录,当然它们都是空! 因为空值不存在于索引列中,所以WHERE子句中对索引列进行空值比较将使ORACLE停用该索引.
低效: (索引失效) SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL; 高效: (索引有效) SELECT … FROM DEPARTMENT WHERE DEPT_CODE >=0;
（27）总是使用索引的第一个列：
如果索引是建立在多个列上, 只有在它的第一个列(leading column)被where子句引用时,优化器才会选择使用该索引. 这也是一条简单而重要的规则，当仅引用索引的第二个列时,优化器使用了全表扫描而忽略了索引
（28）用UNION-ALL 替换UNION ( 如果有可能的话)：
当SQL语句需要UNION两个查询结果集合时,这两个结果集合会以UNION-ALL的方式被合并, 然后在输出最终结果前进行排序. 如果用UNION ALL替代UNION, 这样排序就不是必要了. 效率就会因此得到提高. 需要注意的是，UNION ALL 将重复输出两个结果集合中相同记录. 因此各位还是要从业务需求分析使用UNION ALL的可行性. UNION 将对结果集合排序,这个操作会使用到SORT_AREA_SIZE这块内存. 对于这块内存的优化也是相当重要的. 下面的SQL可以用来查询排序的消耗量
低效：
（29）用WHERE替代ORDER BY：
ORDER BY 子句只在两种严格的条件下使用索引.
ORDER BY中所有的列必须包含在相同的索引中并保持在索引中的排列顺序.
ORDER BY中所有的列必须定义为非空.
WHERE子句使用的索引和ORDER BY子句中所使用的索引不能并列.
例如: 表DEPT包含以下列:
DEPT_CODE PK NOT NULL
DEPT_DESC NOT NULL
DEPT_TYPE NULL
低效: (索引不被使用) SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_TYPE 高效: (使用索引) SELECT DEPT_CODE FROM DEPT WHERE DEPT_TYPE > 0
（30）避免改变索引列的类型.:
当比较不同数据类型的数据时, ORACLE自动对列进行简单的类型转换.
假设 EMPNO是一个数值类型的索引列. SELECT … FROM EMP WHERE EMPNO = ‘123' 实际上,经过ORACLE类型转换, 语句转化为: SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(‘123') 幸运的是,类型转换没有发生在索引列上,索引的用途没有被改变. 现在,假设EMP_TYPE是一个字符类型的索引列. SELECT … FROM EMP WHERE EMP_TYPE = 123 这个语句被ORACLE转换为: SELECT … FROM EMP WHERETO_NUMBER(EMP_TYPE)=123 因为内部发生的类型转换, 这个索引将不会被用到! 为了避免ORACLE对你的SQL进行隐式的类型转换, 最好把类型转换用显式表现出来. 注意当字符和数值比较时, ORACLE会优先转换数值类型到字符类型
31）需要当心的WHERE子句:
某些SELECT 语句中的WHERE子句不使用索引. 这里有一些例子. 在下面的例子里, (1)‘!=' 将不使用索引. 记住, 索引只能告诉你什么存在于表中, 而不能告诉你什么不存在于表中. (2) ‘||'是字符连接函数. 就象其他函数那样, 停用了索引. (3) ‘+'是数学函数. 就象其他数学函数那样, 停用了索引. (4)相同的索引列不能互相比较,这将会启用全表扫描.
（32） a. 如果检索数据量超过30%的表中记录数.使用索引将没有显着的效率提高.
b. 在特定情况下, 使用索引也许会比全表扫描慢, 但这是同一个数量级上的区别. 而通常情况下,使用索引比全表扫描要块几倍乃至几千倍!
（33）避免使用耗费资源的操作:
带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎执行耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序. 通常, 带有UNION, MINUS , INTERSECT的SQL语句都可以用其他方式重写. 如果你的数据库的SORT_AREA_SIZE调配得好, 使用UNION , MINUS, INTERSECT也是可以考虑的, 毕竟它们的可读性很强
（34）优化GROUP BY:
提高GROUP BY 语句的效率, 可以通过将不需要的记录在GROUP BY 之前过滤掉.下面两个查询返回相同结果但第二个明显就快了许多.
· 低效:
下面看一下oracle的执行过程
分析一个SQL语句是怎样在Orcle内部工作的。
A、用户发出SQL请求，打开游标；
B、把SQL语句语法分析，执行计划，数据字典等信息存入内存中共享池内；
C、从数据文件中把相关数据块读入数据缓冲区；
D、做相应操作，若做修改，先加上行级锁，经确认后，把改过前后记录内容存入重做日志缓冲区内；
E、返回结果给用户，关闭游标。
备注：SQL语句大小写敏感的，同样的一个语句，若大小写
不同，oracle需分析执行两次，每句后必以“；”结束。
6. 怎样查看最消耗资源的sql语句 与 ora
1、查询当前系统中正在执行的sql:
SELECT osuser, username, sql_text from v$session a, v$sqltext b
where a.sql_address =b.address order by address, piece;
2、查找死锁的语句:
SELECT l.session_id sid, s.serial#, l.locked_mode,l.oracle_username,
l.os_user_name,s.machine, s.terminal, o.object_name, s.logon_time
FROM v$locked_object l, all_objects o, v$session s
WHERE l.object_id = o.object_id
AND l.session_id = s.sid
ORDER BY sid, s.serial#;
3、查看oracle的权限角色:
select * from dba_role_privs; 授予用户和其他角色的角色
select * from dba_sys_privs; 授予用户和其他角色的系统权限
select * from dba_tab_privs; 数据库中对象的所有授权
select * from user_role_privs; 查看当前用户的角色
4、oracle 查看已经执行过的sql 这些是存在共享池中的：
select * from v$sqlarea t order by t.LAST_ACTIVE_TIME desc;
5、【获取oracle前10条最耗资源的sql语句】：
SELECT * FROM
(
SELECT PARSING_USER_ID
EXECUTIONS,
SORTS,
COMMAND_TYPE,
DISK_READS,
sql_text
FROM v$sqlarea
ORDER BY disk_reads DESC
)
WHERE ROWNUM<11;
7. 送分来了！我的SQL数据库有1G多如何让他小占
请按以下步骤操作:一、可以右击数据库->所有任务->收缩数据库（此方法效果微小）二、导入导出法,操作步骤:1.将数据库中所有用户表的数据导到一个新的数据库，方法右击数据库->所有任务->导出数据2.将数据库中所有用户表删除3.按方法一收缩数据库4.导入数据，把刚才导出的数据再导回数据库5.重新设置数据库的索引和触发器以上方法效果很好友情提示:在数据库在不要设置太多的索引，索引虽然可以加速数据库的查询，但索引会大量消耗空间，而且使数据库的写入变慢
8. 怎样进行sql数据库的优化
在数据库应用系统中编写可执行的SQL语句可以有多种方式实现，但哪一条是最佳方案却难以确定。为了解决这一问题，有必要对SQL实施优化。简单地说，SQL语句的优化就是将性能低下的SQL语句转换成达到同样目的的性能更好的SQL语句。
优化SQL语句的原因
数据库系统的生命周期可以分成: 设计、开发和成品三个阶段。在设计阶段进行优化的成本最低，收益最大。在成品阶段进行优化的成本最高，收益最小。如果将一个数据库系统比喻成一座楼房，在楼房建好后进行矫正往往成本很高而收效很小（甚至可能根本无法矫正），而在楼房设计、生产阶段控制好每块砖瓦的质量就能达到花费小而见效高的目的。
为了获得最大效益，人们常需要对数据库进行优化。数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升全部加起来只占数据库应用系统性能提升的40%左右，其余60%的系统性能提升全部来自对应用程序的优化。许多优化专家甚至认为对应用程序的优化可以得到80%的系统性能提升。因此可以肯定，通过优化应用程序来对数据库系统进行优化能获得更大的收益。
对应用程序的优化通常可分为两个方面: 源代码的优化和SQL语句的优化。由于涉及到对程序逻辑的改变，源代码的优化在时间成本和风险上代价很高(尤其是对正在使用中的系统进行优化) 。另一方面，源代码的优化对数据库系统性能的提升收效有限，因为应用程序对数据库的操作最终要表现为SQL语句对数据库的操作。
对SQL语句进行优化有以下一些直接原因：
1. SQL语句是对数据库(数据) 进行操作的惟一途径，应用程序的执行最终要归结为SQL语句的执行，SQL语句的效率对数据库系统的性能起到了决定性的作用。
2. SQL语句消耗了70%～90%的数据库资源。
3. SQL语句独立于程序设计逻辑，对SQL语句进行优化不会影响程序逻辑，相对于对程序源代码的优化，对SQL语句的优化在时间成本和风险上的代价都很低。
4. SQL语句可以有不同的写法，不同的写法在性能上的差异可能很大。
5. SQL语句易学，难精通。SQL语句的性能往往同实际运行系统的数据库结构、记录数量等有关，不存在普遍适用的规律来提升性能。
传统的优化方法
SQL程序人员在传统上采用手工重写来对SQL语句进行优化。这主要依靠DBA或资深程序员对SQL语句执行计划的分析，依靠经验，尝试重写SQL语句，然后对结果和性能进行比较以试图找到性能较佳的SQL语句。这种做法存在着以下不足：
1. 无法找出SQL语句的所有可能写法。很可能花费了大量的时间也无法找到性能较佳的SQL语句。即便找到了某个性能较佳的SQL语句也无法知道是否存在性能更好的写法。
2. 非常依赖于人的经验，经验的多寡往往决定了优化后SQL语句的性能。
3. 非常耗时间。重写-->校验正确性-->比较性能，这一循环过程需要大量的时间。
根据传统的SQL优化工具的功能，人们一般将优化工具分为以下三代产品：
第一代的SQL优化工具是执行计划分析工具。这类工具对输入的SQL语句从数据库提取执行计划，并解释执行计划中关键字的含义。
第二代的SQL优化工具只能提供增加索引的建议，它通过对输入的SQL语句的执行计划的分析来产生是否要增加索引的建议。这类工具存在着致命的缺点——只分析了一条SQL语句就得出增加某个索引的结论，根本不理会(实际上也无法评估到)增加的索引对整体数据库系统性能的影响。
第三代工具是利用人工智能实现自动SQL优化。
人工智能自动SQL优化
随着人工智能技术的发展和在数据库优化领域应用的深入，在20世纪90年代末优化技术取得了突破性的进展，出现了人工智能自动SQL优化。人工智能自动SQL优化的本质就是借助人工智能技术，自动对SQL语句进行重写，找到性能最好的等效SQL语句。LECCO SQL Expert就采用了这种人工智能技术，其SQL Expert支持Oracle、Sybase、MS SQL Server和IBM DB2数据库平台。其突出特点是自动优化SQL语句。除此以外，还可以以人工智能知识库“反馈式搜索引擎”来重写SQL语句，并找出所有等效的SQL语句及可能的执行计划，通过测试运行为应用程序和数据库自动找到性能最好的SQL语句，提供微秒级的计时; 能够优化Web应用程序和有大量用户的在线事务处理中运行时间很短的SQL语句; 能通过比较源SQL和待选SQL的不同之处，为开发人员提供“边做边学式训练”，迅速提高开发人员的SQL编程技能等等。
该工具针对数据库应用的开发和维护阶段提供了数个特别的模块：SQL语法优化器、PL/SQL集成化开发调试环境(IDE)、扫描器、数据库监视器等。其核心模块之一“SQL 语法优化器”的工作原理大致如下：输入一条源SQL语句，“人工智能反馈式搜索引擎”对输入的SQL语句结合检测到的数据库结构和索引进行重写，产生N条等效的SQL语句输出，产生的N条等效SQL语句再送入“人工智能反馈式搜索引擎”进行重写，直至无法产生新的输出或搜索限额满，接下来对输出的SQL语句进行过滤，选出具有不同执行计划的SQL语句(不同的执行计划意味着不同的执行效率)，最后，对得到的SQL语句进行批量测试，找出性能最好的SQL语句（参见下图）。
图 人工智能自动SQL优化示意图
LECCO SQL Expert不仅能够找到最佳的SQL语句，它所提供的“边做边学式训练”还能够教会开发人员和数据库管理员如何写出性能最好的SQL语句。LECCO SQL Expert的SQL语句自动优化功能使SQL的优化变得极其简单，只要能够写出SQL语句，它就能帮开发人员找到最好性能的写法。
小 结
SQL语句是数据库应用中一个非常关键的部分，它执行性能的高低直接影响着应用程序的运行效率。正因为如此，人们在SQL语句的优化上投入了很大的精力，出现了许多SQL语句优化工具。随着人工智能等相关技术的日益成熟, 肯定还会有更多更好的工具出现，这将会给开发人员提供更多的帮助。