老铁们，大家好，我用自己踩坑的经验告诉你，oraclesql执行顺序 真的没有那么难，难的是没人用简单的话讲明白。今天我就做这个事，顺带把 sql中ordered什么场合使用 也讲清楚。
本文目录
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激增,在实际应用中,我们当然是不希望看到此类增长的.
探讨Oracle查询速度
Oracle查询速度受多方面因素影响，可通过多种方式优化，以下为详细探讨：
影响因素
数据量大小：查询数据量越大，耗时越长。表过于庞大会直接降低查询效率，例如单表数据量达亿级时，全表扫描可能需数秒甚至更久。
索引使用：索引通过快速定位数据块减少读取量，但会增加写入时的维护成本。例如，频繁更新的表若建立过多索引，可能导致写入性能下降。
SQL语句优化：语句规范、去除冗余、优化函数及连接方式对效率至关重要。例如，避免在WHERE子句中使用函数，否则可能导致索引失效。
数据库服务器配置：CPU、内存不足会限制查询性能。例如，内存不足时，Oracle可能频繁使用磁盘交换，显著拖慢查询速度。
锁定时间：数据行被更新、删除或插入时，查询需等待锁定释放。长时间锁定会导致查询阻塞，尤其在并发场景下影响明显。
优化措施
合理使用索引：根据查询频率和数据分布创建索引，避免过度索引。例如，对高频查询的列建立索引，同时定期分析索引使用情况，删除无效索引。
避免全表扫描：通过优化SQL语句强制使用索引，或调整表结构使查询条件匹配索引。例如，为复合索引设计查询条件时，需遵循最左前缀原则。
限制读取行数：利用ROWNUM或FETCH FIRST功能限制结果集大小。例如，分页查询时，通过“WHERE ROWNUM<= 100”减少数据传输量。
利用缓存机制：Oracle的共享池和缓冲区缓存可减少磁盘IO。例如，频繁访问的表数据会被缓存到内存中，后续查询可直接从内存读取。
优化技巧
避免SELECT*：仅查询必要字段，减少数据传输量。例如，查询用户信息时，仅选择“ID、姓名”而非全部字段。
编写简洁SQL：缩短语句长度，优化结构。例如，将多表连接拆分为子查询，或使用EXISTS替代IN提高效率。
采用合适存储方式：分区表可按时间、范围等分割数据，提升查询效率。例如，按日期分区后，查询特定时间段数据仅需扫描部分分区。
利用复杂查询整合：通过WITH子句（CTE）优化多步骤查询，减少重复计算。例如，将复杂报表查询拆分为多个CTE，提升可读性和性能。
使用专业工具：Oracle提供的SQL Tuning Advisor、AWR报告等工具可自动分析性能瓶颈，提供优化建议。例如，通过AWR报告识别高负载SQL并针对性优化。
总结
Oracle查询速度优化需综合考量数据量、索引、SQL、硬件及并发控制等因素。通过合理设计索引、优化SQL、利用缓存及专业工具，可显著提升查询性能。实际应用中，需结合业务场景动态调整策略，并持续监控性能指标，确保数据库高效运行。
hibernate的优化问题
初用HIBERNATE的人也许都遇到过性能问题，实现同一功能，用HIBERNATE与用JDBC性能相差十几倍很正常，如果不及早调整，很可能影响整个项目的进度。
大体上，对于HIBERNATE性能调优的主要考虑点如下:
*数据库设计调整
*HQL优化
* API的正确使用(如根据不同的业务类型选用不同的集合及查询API)
*主配置参数(日志，查询缓存，fetch_size, batch_size等)
*映射文件优化(ID生成策略，二级缓存，延迟加载，关联优化)
*一级缓存的管理
*针对二级缓存，还有许多特有的策略
*事务控制策略。
1、数据库设计
a)降低关联的复杂性
b)尽量不使用联合主键
c) ID的生成机制，不同的数据库所提供的机制并不完全一样
d)适当的冗余数据，不过分追求高范式
2、 HQL优化
HQL如果抛开它同HIBERNATE本身一些缓存机制的关联，HQL的优化技巧同普通的SQL优化技巧一样，可以很容易在网上找到一些经验之谈。
3、主配置
a)查询缓存，同下面讲的缓存不太一样，它是针对HQL语句的缓存，即完全一样的语句再次执行时可以利用缓存数据。但是，查询缓存在一个交易系统(数据变更频繁，查询条件相同的机率并不大)中可能会起反作用:它会白白耗费大量的系统资源但却难以派上用场。
b) fetch_size，同JDBC的相关参数作用类似，参数并不是越大越好，而应根据业务特征去设置
c) batch_size同上。
d)生产系统中，切记要关掉SQL语句打印。
4、缓存
a)数据库级缓存:这级缓存是最高效和安全的，但不同的数据库可管理的层次并不一样，比如，在ORACLE中，可以在建表时指定将整个表置于缓存当中。
b) SESSION缓存:在一个HIBERNATE SESSION有效，这级缓存的可干预性不强，大多于HIBERNATE自动管理，但它提供清除缓存的方法，这在大批量增加/更新操作是有效的。比如，同时增加十万条记录，按常规方式进行，很可能会发现OutofMemeroy的异常，这时可能需要手动清除这一级缓存:Session.evict以及Session.clear
c)应用缓存:在一个SESSIONFACTORY中有效，因此也是优化的重中之重，因此，各类策略也考虑的较多，在将数据放入这一级缓存之前，需要考虑一些前提条件:
i.数据不会被第三方修改(比如，是否有另一个应用也在修改这些数据?)
ii.数据不会太大
iii.数据不会频繁更新(否则使用CACHE可能适得其反)
iv.数据会被频繁查询
v.数据不是关键数据(如涉及钱，安全等方面的问题)。
缓存有几种形式，可以在映射文件中配置:read-only(只读，适用于很少变更的静态数据/历史数据)，nonstrict-read-write，read-write(比较普遍的形式，效率一般)，transactional(JTA中，且支持的缓存产品较少)
d)分布式缓存:同c)的配置一样，只是缓存产品的选用不同，在目前的HIBERNATE中可供选择的不多，oscache, jboss cache，目前的大多数项目，对它们的用于集群的使用(特别是关键交易系统)都持保守态度。在集群环境中，只利用数据库级的缓存是最安全的。
5、延迟加载
a)实体延迟加载:通过使用动态代理实现
b)集合延迟加载:通过实现自有的SET/LIST，HIBERNATE提供了这方面的支持
c)属性延迟加载:
6、方法选用
a)完成同样一件事，HIBERNATE提供了可供选择的一些方式，但具体使用什么方式，可能用性能/代码都会有影响。显示，一次返回十万条记录(List/Set/Bag/Map等)进行处理，很可能导致内存不够的问题，而如果用基于游标(ScrollableResults)或Iterator的结果集，则不存在这样的问题。
b) Session的load/get方法，前者会使用二级缓存，而后者则不使用。
c) Query和list/iterator，如果去仔细研究一下它们，你可能会发现很多有意思的情况，二者主要区别(如果使用了Spring，在HibernateTemplate中对应find,iterator方法):
i. list只能利用查询缓存(但在交易系统中查询缓存作用不大)，无法利用二级缓存中的单个实体，但list查出的对象会写入二级缓存，但它一般只生成较少的执行SQL语句，很多情况就是一条(无关联)。
ii. iterator则可以利用二级缓存，对于一条查询语句，它会先从数据库中找出所有符合条件的记录的ID，再通过ID去缓存找，对于缓存中没有的记录，再构造语句从数据库中查出，因此很容易知道，如果缓存中没有任何符合条件的记录，使用iterator会产生N+1条SQL语句(N为符合条件的记录数)
iii.通过iterator，配合缓存管理API，在海量数据查询中可以很好的解决内存问题，如:
while(it.hasNext()){
YouObject object=(YouObject)it.next();
session.evict(youObject);
sessionFactory.evice(YouObject.class, youObject.getId());
}
如果用list方法，很可能就出OutofMemory错误了。
iv.通过上面的说明，我想你应该知道如何去使用这两个方法了。
7、集合的选用
在HIBERNATE 3.1文档的“19.5. Understanding Collection performance”中有详细的说明。
8、事务控制
事务方面对性能有影响的主要包括:事务方式的选用，事务隔离级别以及锁的选用
a)事务方式选用:如果不涉及多个事务管理器事务的话，不需要使用JTA，只有JDBC的事务控制就可以。
b)事务隔离级别:参见标准的SQL事务隔离级别
c)锁的选用:悲观锁(一般由具体的事务管理器实现)，对于长事务效率低，但安全。乐观锁(一般在应用级别实现)，如在HIBERNATE中可以定义VERSION字段，显然，如果有多个应用操作数据，且这些应用不是用同一种乐观锁机制，则乐观锁会失效。因此，针对不同的数据应有不同的策略，同前面许多情况一样，很多时候我们是在效率与安全/准确性上找一个平衡点，无论如何，优化都不是一个纯技术的问题，你应该对你的应用和业务特征有足够的了解。
9、批量操作
即使是使用JDBC，在进行大批数据更新时，BATCH与不使用BATCH有效率上也有很大的差别。我们可以通过设置batch_size来让其支持批量操作。
举个例子，要批量删除某表中的对象，如“delete Account”，打出来的语句，会发现HIBERNATE找出了所有ACCOUNT的ID，再进行删除，这主要是为了维护二级缓存，这样效率肯定高不了，在后续的版本中增加了bulk delete/update，但这也无法解决缓存的维护问题。也就是说，由于有了二级缓存的维护问题，HIBERNATE的批量操作效率并不尽如人意!
关于 oraclesql执行顺序 和 sql中ordered什么场合使用 讲解完毕，愿你学以致用。