做记录: 今天有一个有153万条数据的表,发现查询很慢: select count(y) as transfereeNum,x from t_ast_subject_invest_order GROUP BY x; 执行时间大概2-3s .. 给字段x 加上索引后,时间为0.007s . 查询速度明显提升. 2. 关于in 和 exist 效率问题 #外表内表同量级 select o.* from x o and o.trans_from_order IN (select t1.ORDER_NO
大多数情况下,oracle数据库内置的查询优化策略还是很成功的,但偶尔也有犯2的时候,即使有索引,也会做全表扫描,可以参考以下语句的写法,强制让select语句使用索引 CREATE OR REPLACE VIEW V_RES_CBA AS SELECT /*+INDEX(SEG IDX_T_RES_ALLOSEG_ALLOID)*/ ALLO.ALLOID AS RESID, NULL AS AWB, ALLO.ALLOTMENT AS ALLO_ID, DAYS.FDATE ) AS FDA
这里要纠正一个网上很多教程说的模糊匹配不能走索引的说法,因为在看<收获,不止SQL优化>一书,里面举例说到了,并且自己也跟着例子实践了一下,确实like一些特殊情况也是可以走索引的 例子来自<收获,不止SQL优化>一书,实践准备: //建表,注意要非空数据 drop table t purge; create table t as select * from dba_objects where object_id is not null; select * from t; //更新
在ITPUB 上看到一个帖子 http://www.itpub.net/thread-1875212-1-1.html 同一条SQL语句,只有查询条件不一样,查询返回的结果集都为0,一个走了全表扫描,一个走索引.查看全表扫描的SQL语句:SQL走全表,产生了2422609个逻辑读,cost为535KSQL> SELECT URL,YHZH,HFRZY,HFLR,SPURL,TPURL,YPURL,SCSJ,LY,JCSJ FROM YHXX_HFXX T 2 WHERE T.URL=
NULL值是关系数据库系统布尔型(true,false,unknown)中比较特殊类型的一种值,通常称为UNKNOWN或空值,即是未知的,不确定的.由于NULL存在着无数的可能,因此NULL值也不等于NULL值,所以与NULL值相关的操作同样都为NULL值.正是基于这样一个特性,对于NULL值列上的B树索引导致了is null/is not null不走索引的情形,下面描述了NULL值与索引以及索引NULL列上的执行计划,如何使得NULL值走索引的情形.注:本文仅仅讨论的是B树索引上的NULL值
(1)索引唯一扫描(index unique scan) 通过唯一索引查找一个数值经常返回单个ROWID.如果该唯一索引有多个列组成(即组合索引),则至少要有组合索引的引导列参与到该查询中,如创建一个索引:create index idx_test on emp(ename, deptno, loc).则select ename from emp where ename = ‘JACK’ and deptno = ‘DEV’语句可以使用该索引.如果该语句只返回一行,则存取方法称为索引唯一扫描.而
外键加索引是常识,必须牢记.本来不想写这样的简单案例.可是连续遇到好几起外键不加索引导致性能问题,所以还是写一下. 一个兄弟问我 delete from Sa_Sales_Comm_Detail s where s.sales_commission_id=24240; ---删除105条数据很慢.要跑几十秒到上百秒 这个表总数据才35万行,sales_commission_id 列有索引,运行计划也确实是走了索引. 走索引返回105 条数据.不可能跑几十秒跑上百秒的. 之后我问他 select
使用Oracle的instr函数与索引配合提高模糊查询的效率 一般来说,在Oracle数据库中,我们对tb表的name字段进行模糊查询会采用下面两种方式:1.select * from tb where name like '%XX%';2.select * from tb where instr(name,'XX')>0; 若是在name字段上没有加索引,两者效率差不多,基本没有区别. 为提高效率,我们在name字段上可以加上非唯一性索引:create index idx_tb_name on
有些情况下,表中创建了索引但是EXPLAIN的查看执行计划的时候发现并没有走索引.是因为优化器认为该语句不使用索引效率更好. 当然也可以强制走索引.类似: SELECT uid,uname FROM tab_name force index(ind_id); SELECT SQL_NO_CACHE uid,uname FROM tab_name ; 不走逻辑IO,走物理IO.
Mysql: mysql between 日期索引 索引问题-日期索引使用 表结构: dep_date dep arr 联合索引: ind_coll_date_route (dep_date ,dep,arr) 这两天发现原来的查询效率慢了,使用explain 查看,居然没有使用索引, 我的索引是日期类型的,首先想到的是mysql对日期类型的索引的处理机制是不是不同,在where条件里试了几种,发现效果都差不多, where dep_date >= ‘20161121’ where dep_d