网站页面设计流程,优秀手机网站设计,开锁换锁做网站,建设银行啦卡信用网站一、oracle 数据库TIMESTAMP 时间字段#xff0c;设置索引后#xff0c;通过该字段进行排序#xff0c;索引排序不生效问题 1. 记录下在工作中遇到的一次索引问题 问题描述#xff1a; 数据库#xff1a;oracle#xff1b; 日志记录表中的一个创建时间#xff08;create…一、oracle 数据库TIMESTAMP 时间字段设置索引后通过该字段进行排序索引排序不生效问题 1. 记录下在工作中遇到的一次索引问题 问题描述 数据库oracle 日志记录表中的一个创建时间create_time字段类型timestamp字段在该字段设置了索引后通过该字段进行排序时索引排序并没有起作用。 解决方式 将create_time字段类型修改为varchar2类型格式为 yyyy-MM-dd HH24:mi:ss再次排序时索引排序生效效率也提高了不少。难道timestamp排序时索引不能使用吗具体原因还需要进一步落实等有时间在深入的了解。
二、oracle 时间条件值范围越大就不走索引问题解决
oracle 时间条件值范围越大就不走索引问题解决使用强制索引 在写一个比较复杂的统计语句的时候其中涉及到了时间的条件。但在执行测试过程中发现开始时间和结束时间的范围在两三天的时候执行计划里是走的索引查询很快当把时间范围扩大到五天、十天、一个月的时候执行计划里反而全表扫描了查询效率慢了几十倍不止这对于统计一个大表来说是致命的。 经过资料查询发现在oracle中有一个因素影响是进行全表扫描还是索引扫描那就是查找的数据如果超过总数的20%左右就会影响到扫描方式不过这只是一个因素不完全取决于它。这时候如果对业务清晰可以尝试使用强制索引测试查询语句的性能。
使用强制索引在SELECT 后面加上/…/ 中间加上索引的属性代码如下
SELECT /*index(t pk_emp)*/* FROM EMP T
--强制索引/*.....*/第一个星星后不能有空格里边内容结构为加号index(表名 空格 索引名)。
--如果表用了别名注释里的表也要使用别名。在使用了强制索引后发现日期跨度比较大的时候仍然用到了索引查询速度由原来的一分钟提升到了1-2秒。
———————————————— 原文链接oracle 时间条件值范围越大就不走索引问题解决使用强制索引_oracle日期大于小于走索引-CSDN博客
三、Oracle小于条件导致索引失效
ORACLE建索引的小发现 基础索引建立 创建一般索引Non-Unique 创建唯一索引Unique 对订单表的ACCT_DATE进行查询 执行计划 小于条件的执行计划 (小于等于执行计划与小于一样) SQL: 执行计划: 大于条件的执行计划 (大于等于执行计划与大于一样) SQL: 执行计划: 结论 基础索引建立 创建一般索引Non-Unique CREATE INDEX IDX_ORDER_TASK ON IC_GRANT_ORDER (ACCT_DATE ASC); 1 推荐这种如果需要唯一可以单加一个唯一约束这样以后改成非唯一只需要去除约束即可。
创建唯一索引Unique CREATE UNIQUE INDEX IDX_ORDER_TASK ON IC_GRANT_ORDER (ACCT_DATE ASC); 1 如果后期要改成非唯一索引需要删除索引重新建立
对订单表的ACCT_DATE进行查询 执行计划 TABLE ACCESS FULL全表扫描 INDEX RANGE SCAN 索引扫描 TABLE ACCESS BY INDEX ROWID通过ROWID唯一索引查询 本次建立的是Non-Unique索引底层会通过索引字段和ROWID组成联合索引查询时会先查询索引字段然后查询ROWID快速定位数据。
小于条件的执行计划 (小于等于执行计划与小于一样) SQL: explain plan for select id from IC_GRANT_ORDER where ACCT_DATE20200601 and send_status04; SELECT * from table(dbms_xplan.display); 1 2 3 执行计划: Plan hash value: 3153622128 ------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 9 | 405 | 718 (1)| 00:00:09 | |* 1 | TABLE ACCESS FULL| IC_GRANT_ORDER | 9 | 405 | 718 (1)| 00:00:09 | ------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(SEND_STATUS04 AND ACCT_DATE20200601) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 大于条件的执行计划 (大于等于执行计划与大于一样) SQL: explain plan for select id from IC_GRANT_ORDER where ACCT_DATE20200623 and send_status04; SELECT * from table(dbms_xplan.display); 1 2 3 执行计划: Plan hash value: 2309823823 ---------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 45 | 3 (0)| 00:00:01 | |* 1 | TABLE ACCESS BY INDEX ROWID| IC_GRANT_ORDER | 1 | 45 | 3 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | IDX_ORDER_TASK | 1 | | 2 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(SEND_STATUS04) 2 - access(ACCT_DATE20200623) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 结论 sql中的非唯一索引字段判断如果是包含小于条件会导致索引失效。大于和等于正常走索引。 小于失效的原因根据执行计划可知底层会将非唯一索引与rowid合为联合索引因此范围无法使用索引。但是大于为何有效目前还没有搞清楚 ———————————————— 原文链接Oracle小于条件导致索引失效_oracle小于等于走索引吗-CSDN博客
