acy_2013-08-06_Oracle执行计划课件.ppt

表连接操作3 3,排序合并连接-MERGE JOIN 两个表都使用全表扫描，分别进行排序，然后再合并成查询的结果集。 极少情况适合。只有包含两个表的决大多数记录的查询适合。 A表全表扫描 B表全表扫描 A表排序 B表排序 输出结果集 合并 Step1:全表扫描 对查询影响最大的就是全表扫描-Table Access Full. 计执行划中所有的全表扫描都值得怀疑.除非是数据量非常小的表 可能引起全表扫描的原因： 表上没有索引 没有WHERE条件 对索引字段使用了内置函数，如 To(Dcredate)=‘2005-02-15’ Like操作符而参数以“%”开始 表记录非常少 Step2:驱动表－1 驱动表 最内层的驱动表是不是能在执行过程中得到最小的中间数据集？ 例如：查询销售订单明细，涉及三个表，订单主表，订单附表,存货基本档案表。条件中包含：订单日期等于某天和存货编码等于某个值。 方案一：如果以订单主表为驱动表，可以使用日期上的索引过滤出所有的当天的订单，然后关联附表，最后再关联到存货档案表，过滤出相应存货。 订单附表 订单主表 存货档案表 日期索引 主表PK索引 存货主键索引 Step2:驱动表－2 方案二：如果以存货档案为驱动表，可以使用编码上的索引过滤出所有存货，然后关联订单附表，得到所有存货符合条件的订单附表记录，最后再用订单附表上的主表主键关联主表，判断订单主表上的日期是否符合条件，最后得到结果集。 订单附表 订单主表 存货档案表 编码索引 存货ID索引 主表主键索引 结论：如果按照存货去过滤，得到订单附表上符合条件记录会较少，认为方案二更优。 Step3:不该建的索引 错误索引： 对于只有少数一个可能值的列，不应该建索引。如单据状态，单据主表上的部门人员，附表上的仓库，库存组织等。 索引不是越多越好。数据的插入，删除和修改都需要维护索引表，也是有成本的。 建议建索引的列。所有可能用做查询条件的日期列,客户列；附表上的主表主键列，存货列，来源单据列；基本档案的编码列等。 Step4:复合索引列顺序 对复合索引，应将重复值少的列作为先导列 例如订单附表上有来源单据类型(srctype)和来源单据ID(srcid),建立索引的顺序应该是srcid,srctype. 如果将srctype列作为先导列，可能在查询时，没有srcid的条件也使用这个索引扫描，其结果是扫描了大半个表，比全表扫描还慢。 Step5:非最优索引 对一个表存在多个索引的列作为条件，解析中可能使用了非最优索引 使用提示，指定使用某个索引(存在SQL兼容问题，不推荐) 将索引尽可能多的使用条件 使用内置函数或运算使不想使用的条件列失效。 整型数据列+0 字符型加trim函数 例如：在进行调拨的时候需要判断这个仓库中此存货不存在没有记帐的出库单 Select count(*) from XXX where pk_inv=:1 and status=0 这个查询会用到存货索引，但是速度还是慢。但是仔细分析会发现，其实实际运行中没记帐的出库单比例很少，如果在存货索引上再加上状态列，可以过滤更少的数据，速度将大大提高。 Step6:数据非均匀分布 对于某些SQL可能存在时快时慢，这个即可能是数据的分布不均导致 举例：做销售订单时，去判断此客户是否存在未结算订单。SQL语句： 这个语句在做多数客户的时候没有感觉，但是在做某一两个客户时速度奇慢，查其执行计划，也使用了主表上的客户索引。 Select .. From so_order,so_order_b,.. where so_order.pk=so_order_b.pk and ccustomerid=:1 and …….. 最后发现情况是这样的：企业是做批发业务的，政策法规上不允许直接销售给个人，内部职工需要购买时都是按照统一个特定的客户开票，因此数据库中数据严重不均，此客户的订单数量大于总数的10%。一进行这样的查询就严重占用数据库资源，导致系统相应速度慢。 解决的办法：这种行为都是现金交易根本不需要进行检查，查询的结果永远是空。程序绕过这个检查就行了。 Step7:EXIST 查询基本格式 例： select count(*) from prm_adjustprice main,prm_adjustprice_b detail where main.cadjpriceid=detail.CADJPRICEID and main.cadjpriceid in (1,2) and exists (select * from bd_invmandoc where bd_invmandoc.SEALFLAG=N‘ and