网站建设当中的技术解决方案,直接通过ip访问网站,策划公司起什么名字好,网站建设目录结构doc虽然你这列上建了索引#xff0c;查询条件也是索引列#xff0c;但最终执行计划没有走它的索引。下面是引起这种问题的几个关键点。
列与列对比
某个表中#xff0c;有两列#xff08;id和c_id#xff09;都建了单独索引#xff0c;下面这种查询条件不会走索引
select…虽然你这列上建了索引查询条件也是索引列但最终执行计划没有走它的索引。下面是引起这种问题的几个关键点。
列与列对比
某个表中有两列id和c_id都建了单独索引下面这种查询条件不会走索引
select * from test where idc_id;
这种情况会被认为还不如走全表扫描。
存在NULL值条件
我们在设计数据库表时应该尽力避免NULL值出现如果非要不可避免的要出现NULL值也要给一个DEFAULT值数值型可以给0、-1之类的 字符串有时候给空串有问题就给一个空格或其他。
如果索引列是可空的很可能是不会给其建索引的索引值是少于表的count(*)值的所以这种情况下执行计划自然就去扫描全表了。
select * from test where id is not null;
NOT条件
我们知道建立索引时给每一个索引列建立一个条目如果查询条件为等值或范围查询时索引可以根据查询条件去找对应的条目。
反过来当查询条件为非时索引定位就困难了执行计划此时可能更倾向于全表扫描这类的查询条件有、NOT、in、not exists
select * from test where id500;
select * from test where id in (1,2,3,4,5);
select * from test where not in (6,7,8,9,0);
select * from test where not exists (select 1 from test_02 where test_02.idtest.id);
LIKE通配符
当使用模糊搜索时尽量采用后置的通配符例如name||’%’因为走索引时其会从前去匹配索引列这时候是可以找到的如果采用前匹配那么查索引就会很麻烦比如查询所有姓张的人就可以去搜索’张%’。
相反如果你查询所有叫‘明’的人那么只能是%明。这时候索引如何定位呢前匹配的情况下执行计划会更倾向于选择全表扫描。后匹配可以走INDEX RANGE SCAN。
所以业务设计的时候尽量考虑到模糊搜索的问题要更多的使用后置通配符。
select * from test where name like 张||%;
条件上包括函数
查询条件上尽量不要对索引列使用函数比如下面这个SQL
select * from test where upper(name)SUNYANG;
这样是不会走索引的因为索引在建立时会和计算后可能不同无法定位到索引。但如果查询条件不是对索引列进行计算那么依然可以走索引。比如
select * from test where nameupper(sunyang);--INDEX RANGE SCAN
这样的函数还有to_char、to_date、to_number、trunc等。
复合索引前导列区分大
当复合索引前导列区分小的时候我们有INDEX SKIP SCAN当前导列区分度大且查后导列的时候前导列的分裂会非常耗资源执行计划想还不如全表扫描来的快然后就索引失效了。
select * from test where ownersunyang;
数据类型的转换
当查询条件存在隐式转换时索引会失效。比如在数据库里id存的number类型但是在查询时却用了下面的形式
select * from sunyang where id123;
Connect By Level
使用connect by level时不会走索引。
谓词运算
我们在上面说不能对索引列进行函数运算这也包括加减乘除的谓词运算这也会使索引失效。建立一个sunyang表索引为id看这个SQL
select * from sunyang where id/2:type_id;
这里很明显对索引列id进行了’/2’除二运算这时候就会索引失效这种情况应该改写为
select * from sunyang where id:type_id*2;
就可以使用索引了。
Vistual Index
先说明一下虚拟索引的建立是否有用需要看具体的执行计划如果起作用就可以建一个如果不起作用就算了。
普通索引这么建
create index idx_test_id on test(id);
虚拟索引Vistual Index这么建
create index idx_test_id on test(id) nosegment;
做了一个实验首先创建一个表
CREATE TABLE test_1116( id number, a number );
CREATE INDEX idx_test_1116_id on test_1116(id);
CREATE INDEX idx_test_1116_a on test_1116(a)nosegment;
其中id为普通索引a为虚拟索引。
在表中插入十万条数据
begin
for i in 1 .. 100000 loop insert into test_1116 values (i,i);
end loop;
commit;
end;
接着分别去执行下面的SQL看时间由于在内网机做实验图贴不出来数据保证真实性。
select count(id) from test_1116;--第一次耗时0.061秒--第二次耗时0.016秒
select count(a) from test_1116; --第一次耗时0.031秒--第二次耗时0.016秒
因为在执行过一次后oracle对结果集缓存了所以第二次执行耗时不走索引走内存就都一样了。可以看到在这种情况下虚拟索引比普通索引快了一倍。
具体虚拟索引的使用细节这里不再展开讨论。
Invisible Index
Invisible Index是oracle 11g提供的新功能对优化器还接到前面博客里讲到的CBO吗不可见我感觉这个功能更主要的是测试用假如一个表上有那么多索引一个一个去看执行计划调试就很慢了这时候不如建一个对表和查询都没有影响的Invisible Index来进行调试就显得很好了。
通过下面的语句来操作索引
alter index idx_test_id invisible;alter index idx_test_id visible;
如果想让CBO看到Invisible Index需要加入这句
alter session set optimizer_use_invisible_indexes true;
基本就这些了有问题欢迎留言指出共同进步
