原标题：sql优化in用什么代替，sql优化in 1000个参数
导读：
存储过程中用什么可以替代游标Mysql存储过程优化——使用临时表代替游标。Mysql游标在操作小数据量时比较方便，效率可观，但操作大数据量，速度比较慢，甚至直接产生系统错误。一...
存储过程中用什么可以替代游标
Mysql存储过程优化——使用临时表代替游标。
Mysql游标在操作小数据量时比较方便，效率可观，但操作大数据量，速度比较慢，甚至直接产生系统错误。
一般说来，当操作的数据超过1万条时，就避免用游标吧。
为了测试游标性能，写了下面一个游标对IDC_Gather_Info表中数据进行遍历
下面是当表中数据分别为15万、5万、1万时游标的表现：
1.数据量15万，存储过程执行失败，提示错误：Incorrect key file for table'/tmp/#sql_3044_0.MYI';try to repair it
2.数据量5万，执行成功，耗时31.051s
3.数据量1万，执行成功，耗时1.371s
下面使用临时表替换游标：
1.数据量15万，执行成功，耗时8.928s
2.数据量5万，执行成功，耗时2.994s
3.数据量1万，执行成功，耗时0.634s
可以看到Mysql的游标在处理大一点的数据量时还是比较乏力的，仅适合用于操作几百上千的小数据量。
pl-sql中ordered什么场合使用
在执行sql优化的时候使用。
oracle的sql优化基本上可以说有一个目标，两种方式。
一个目标就是说：要减少查询所需要的逻辑读次数，如果概念不懂可以查询网络；
两种方式可以概括为：
1，增加适当的索引；
2，通过搜集统计信息改变执行计划，或者手工使用hints影响oracle对执行计划的选择；
这里你提到的ordered就是hint的一种，它的作用是，指定按照表在from后面出现的先后顺序对表进行关联，方式是将ordered关键词放在hints的专用格式中/*+ ordered*/
比如说，对于下面的sql来说
select* from t1,t2
where t1.id= t2.id
我们假设oracle当前的默认执行计划是t1为驱动表，t2为被探测表，
select
nest loop
t1
t2
那么我们可以通过hint，ordered强制让oracle用t2作为驱动表，方式如下
select/*+ ordered*/*
from t2,t1
where t1.id= t2.id
这是的执行计划将是
select
nested loop
t2
t1
-------------------------------
ORDERED提示强制Oracle按照From子句中表出现的顺序进行表连接。
通过ordered提示，可以避免CBO SQL解析过程中的表连接评估，从而避免Oracle产生错误的执行计划，或者强制Oracle按照我们指定的方式执行。
在很多时候，当我们清楚地了解数据结构和数据分布之后，就可以通过ORDERED提示来提高SQL性能。
通过以下例子我们来说明一下Ordered提示的作用.
1.不加Hints时SQL的执行计划
SQL> set autotrace trace explainSQL> SELECT COUNT(*) 2 FROM t_small, t_max, t_middle 3 WHERE t_small.object_id= t_middle.object_id 4 AND t_middle.object_id= t_max.object_id;Execution Plan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE(Cost=194 Card=1 Bytes=12) 1 0 SORT(AGGREGATE) 2 1 HASH JOIN(Cost=194 Card=400 Bytes=4800) 3 2 HASH JOIN(Cost=42 Card=100 Bytes=800) 4 3 TABLE ACCESS(FULL) OF'T_SMALL'(Cost=2 Card=100 Bytes=400) 5 3 TABLE ACCESS(FULL) OF'T_MIDDLE'(Cost=39 Card=28447 Bytes=113788) 6 2 TABLE ACCESS(FULL) OF'T_MAX'(Cost=151 Card=113792 Bytes=455168)
我们可以通过10053事件跟踪一下该SQL的解析:
SQL> alter session set events='10053 trace name context forever,level 1';Session altered.SQL> explain plan for 2 SELECT COUNT(*) 3 FROM t_small, t_max, t_middle 4 WHERE t_small.object_id= t_middle.object_id 5 AND t_middle.object_id= t_max.object_id; Explained.
查看Trace文件可以看到,Oracle需要进行3!(6)次表连接顺序的评估:
bash-2.03$ cat testora9_ora_10862.trc|grep"Join order"Join order[1]: T_SMALL [T_SMALL] T_MIDDLE [T_MIDDLE] T_MAX [T_MAX] Join order[2]: T_SMALL [T_SMALL] T_MAX [T_MAX] T_MIDDLE [T_MIDDLE] Join order[3]: T_MIDDLE [T_MIDDLE] T_SMALL [T_SMALL] T_MAX [T_MAX] Join order[4]: T_MIDDLE [T_MIDDLE] T_MAX [T_MAX] T_SMALL [T_SMALL] Join order[5]: T_MAX [T_MAX] T_SMALL [T_SMALL] T_MIDDLE [T_MIDDLE] Join order[6]: T_MAX [T_MAX] T_MIDDLE [T_MIDDLE] T_SMALL [T_SMALL]
2.当我们使用Ordered提示之后
SQL的执行计划如下(from子句后的表顺序作了调整):
SQL> SELECT/*+ ordered*/ COUNT(*) 2 FROM t_middle, t_small, t_max 3 WHERE t_small.object_id= t_middle.object_id 4 AND t_middle.object_id= t_max.object_id; Execution Plan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE(Cost=197 Card=1 Bytes=12) 1 0 SORT(AGGREGATE) 2 1 HASH JOIN(Cost=197 Card=400 Bytes=4800) 3 2 HASH JOIN(Cost=45 Card=100 Bytes=800) 4 3 TABLE ACCESS(FULL) OF'T_MIDDLE'(Cost=39 Card=28447 Bytes=113788) 5 3 TABLE ACCESS(FULL) OF'T_SMALL'(Cost=2 Card=100 Bytes=400) 6 2 TABLE ACCESS(FULL) OF'T_MAX'(Cost=151 Card=113792 Bytes=455168)
再看10053的跟踪Trace文件:
bash-2.03$ grep"Join order" testora9_ora_10918.trcJoin order[1]: T_MIDDLE [T_MIDDLE] T_SMALL [T_SMALL] T_MAX [T_MAX]
Oracle只需要按照表在From子句中的出现顺序进行连接,从而按照我们的意图进行解析或执行.
这就是Ordered提示的基本作用,本例只是一个示范说明,后者的执行计划使得Cost激增,在实际应用中,我们当然是不希望看到此类增长的.
