索引就好象一本字典的目录。凭借字典的目录，我们可以非常迅速的找到我们所需要的条目。数据库也是如此。凭借Oracle数据库的索引，相关语句可以迅速的定位记录的位置，而不必去定位整个表。 虽然说，在表中是否创建索引，不会影响到Oracle数据库的使用，也不会影响数据库语句的使用。这就好像即使字典没有目录的话，用户仍然可以使用它一样。可是，若字典没有目录，那么可想而知，用户要查某个条目的话，其不得不翻遍整本字典。数据库也是如此。若没有建立相关索引的话，则数据库在查询记录的时候，不得不去查询整个表。当表中的记录比较多的时候，其查询效率就会很低。所以，合适的索引，是提高数据库运行效率的一个很好的工具。 不过，并不是说表上的索引越多越好。过之而不及。故在数据库设计过程中，还是需要为表选择一些合适的索引。宁缺勿滥，这是建立索引时的一个遵循标准。在理论上，虽然一个表可以设置无限的索引。但是，数据库管理员需要知道，表中的索引越多，维护索引所需要的开销也就越大。每当数据表中记录有增加、删除、更新变化的时候，数据库系统都需要对所有索引进行更新。故数据库表中的索引绝对不是多多益善。具体来说，在索引建立上，笔者对大家有如下建议。 建议一：在基数小的字段上要善于使用位图索引。 基数是位图索引中的一个基本的定义，它是指数据库表中某个字段内容中不重复的数值。如在员工信息表中的性别字段，一般就只有男跟女两个值，所以，其基数为2;婚姻状况字段的话，则其只有已婚、未婚、离婚三种状态，其基数就为3;民族一览内也是只有有限的几个值。 对于要查询基数小的字段，如现在用户想查找所有婚姻状况为“已婚”的“女性”时，利用位图索引可以提高查询的效率。这主要是因为标准索引是通过在索引中保存排序过的索引列以及对应的ROWID来实现的。若我们在基数小的列上建立标准索引的话，则其会返回大量的记录。 而当我们在创建位图索引的时候，在Oracle会对整个表进行扫描，并且会为索引列的每个取值建立一个位图。若内容相同，则在位图上会以一个相同的数字表示。此时，若这个字段的基数比较小的话，则若需要实现对整个字段的查询的话，效率就会非常的高。因为此时，数据库只要位图中数字相同的内容找出来即可。 除了在数据表某列基数比较小的情况下，采用位图索引外，我们往往在一些特殊的情况下，也会建议采用位图索引。最常见的情况是，在Where限制条件中，若我们多次采用AND或者OR条件时，也建议采用位图索引。因为当一个查询饮用了一些部署了位图索引的列的时候，这些位图可以很方便的与AND或者Or 运算符操作结合以快速的找出用户所需要的记录。 但是，这里要注意，不是在条件语句中包含运算符的时候，采用位图索引都能够提供比较高的效率。一般来说，只有AND 或者OR运算符的时候，位图索引才会比较具有优势。若此时用户采用大于号或者不等于号作为条件语句中的限制条件的时候，则往往采用标准索引具有更大的优势。 所以，笔者在数据库设置中，一般只有在三种情况下才采用位图索引。一是列的基数比较小，而有可能需要根据这些字段的内容查找相关的记录;二是在条件语句中，用到了AND或者OR运算符的时候。除了这两种情况外，最好能够采用其他适合的索引。第三种情况是，需要用到NULL作为查询的限制条件。因为标准查询一般情况下，会忽略所有的NULL值列。也就是说，若需要查询“所有没有身份证号码”的员工的信息的时候，标准索引并不能够起到加速查询速度的作用。此时，就需要采用位图索引。因为位图索引会记录相关的NULL值列信息。 建议二：创建索引的一些限制条件。 并不说，表或者列建立的索引越多越好。相反，索引建的越多，有时会反而会影响数据库运行的整体性能。所以，在建立索引的时候，仍然会有一些限制条件。 一是不要对一些记录内容比较少的表建立索引。在一个应用系统设计的时候，如设计一个ERP系统的数据库，其虽然有几千张表。但是，并不是每张表都有大量记录的。相反，其中有近一半左右的数据表，可能其存储的数据不会超过百条。如员工登陆帐户密码表、企业部门信息表等等。对于这些记录内容比较少的表，我们建立最好不要为其建立索引。无论是表上的，还是字段上，都不要建立索引。
创新互联建站为企业级客户提高一站式互联网+设计服务，主要包括成都网站设计、成都网站建设、APP应用开发、微信平台小程序开发、宣传片制作、LOGO设计等，帮助客户快速提升营销能力和企业形象，创新互联各部门都有经验丰富的经验，可以确保每一个作品的质量和创作周期，同时每年都有很多新员工加入，为我们带来大量新的创意。
会用到单独的索引
组合索引对查询字段的顺序是有很高的要求的
select * from table where first_result='XXX' and ne_id=1111
或者
select * from table where first_result='XXX'
只有上述2种情况才会用到这个组合索引, 第一个字段必须用到
创建索引语法：
CREATE [UNIQUE] | [BITMAP] INDEX index_name
--unique表示唯一索引
ON table_name([column1 [ASC|DESC],column2
--bitmap，创建位图索引
[ASC|DESC],…] | [express])[TABLESPACE tablespace_name][PCTFREE n1]
--指定索引在数据块中空闲空间
[STORAGE (INITIAL n2)][NOLOGGING]
--表示创建和重建索引时允许对表做DML操作，默认情况下不应该使用
[NOLINE][NOSORT];
--表示创建索引时不进行排序，默认不适用，如果数据已经是按照该索引顺序排列的可以使用
扩展资料：
1、如果有两个或者以上的索引，其中有一个唯一性索引，而其他是非唯一，这种情况下oracle将使用唯一性索引而完全忽略非唯一性索引
2、至少要包含组合索引的第一列（即如果索引建立在多个列上，只有它的第一个列被where子句引用时，优化器才会使用该索引）
3、小表不要简历索引
4、对于基数大的列适合建立B树索引，对于基数小的列适合简历位图索引
5、列中有很多空值，但经常查询该列上非空记录时应该建立索引
6、经常进行连接查询的列应该创建索引
7、使用create index时要将最常查询的列放在最前面
8、LONG（可变长字符串数据，最长2G）和LONG RAW（可变长二进制数据，最长2G）列不能创建索引
9、限制表中索引的数量（创建索引耗费时间，并且随数据量的增大而增大；索引会占用物理空间；当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，降低了数据的维护速度）
Oracle 建立索引及SQL优化
Oracle 建立索引及SQL优化
数据库索引:
索引有单列索引
复合索引之说
如何某表的某个字段有主键约束和唯一性约束，则Oracle 则会自动在相应的约束列上建议唯一索引。数据库索引主要进行提高访问速度。
建设原则:
1、索引应该经常建在Where 子句经常用到的列上。如果某个大表经常使用某个字段进行查询，并且检索行数小于总表行数的5%。则应该考虑。
2、对于两表连接的字段，应该建立索引。如果经常在某表的一个字段进行Order By 则也经过进行索引。
3、不应该在小表上建设索引。
优缺点:
1、索引主要进行提高数据的查询速度。 当进行DML时，会更新索引。因此索引越多，则DML越慢，其需要维护索引。 因此在创建索引及DML需要权衡。
创建索引:
单一索引:Create Index Index-Name On Table_Name(Column_Name);
复合索引: Create Index i_deptno_job on emp(deptno,job); —在emp表的deptno、job列建立索引。
select * from emp where deptno=66 and job='sals' -走索引。
select * from emp where deptno=66 OR job='sals' -将进行全表扫描。不走索引
select * from emp where deptno=66 -走索引。
select * from emp where job='sals' -进行全表扫描、不走索引。
如果在where 子句中有OR 操作符或单独引用Job 列(索引列的后面列) 则将不会走索引，将会进行全表扫描。
Sql 优化:
当Oracle数据库拿到SQL语句时，其会根据查询优化器分析该语句，并根据分析结果生成查询执行计划。
也就是说，数据库是执行的查询计划，而不是Sql语句。
查询优化器有rule-based-optimizer(基于规则的查询优化器) 和Cost-Based-optimizer(基于成本的查询优化器)。
其中基于规则的查询优化器在10g版本中消失。
对于规则查询，其最后查询的是全表扫描。而CBO则会根据统计信息进行最后的选择。
1、先执行From -Where -Group By-Order By
2、执行From 字句是从右往左进行执行。因此必须选择记录条数最少的表放在右边。这是为什么呢？
3、对于Where字句其执行顺序是从后向前执行、因此可以过滤最大数量记录的条件必须写在Where子句的末尾，而对于多表之间的连接，则写在之前。
因为这样进行连接时，可以去掉大多不重复的项。
4. SELECT子句中避免使用(*)ORACLE在解析的过程中, 会将’*’ 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间
5、索引失效的情况:
① Not Null/Null 如果某列建立索引,当进行Select * from emp where depto is not null/is null。 则会是索引失效。
② 索引列上不要使用函数,SELECT Col FROM tbl WHERE substr(name ,1 ,3 ) = 'ABC'
或者SELECT Col FROM tbl WHERE name LIKE '%ABC%' 而SELECT Col FROM tbl WHERE name LIKE 'ABC%' 会使用索引。
③ 索引列上不能进行计算SELECT Col FROM tbl WHERE col / 10 10 则会使索引失效，应该改成
SELECT Col FROM tbl WHERE col 10 * 10
④ 索引列上不要使用NOT （ != 、 ）如:SELECT Col FROM tbl WHERE col ! = 10
应该 改成：SELECT Col FROM tbl WHERE col 10 OR col 10 。
6、用UNION替换OR(适用于索引列)
union:是将两个查询的结果集进行追加在一起，它不会引起列的变化。 由于是追加操作，需要两个结果集的列数应该是相关的，
并且相应列的数据类型也应该相当的。union 返回两个结果集，同时将两个结果集重复的项进行消除。 如果不进行消除，用UNOIN ALL.
通常情况下, 用UNION替换WHERE子句中的OR将会起到较好的效果. 对索引列使用OR将造成全表扫描. 注意, 以上规则只针对多个索引列有效.
如果有column没有被索引, 查询效率可能会因为你没有选择OR而降低. 在下面的例子中, LOC_ID 和REGION上都建有索引.
高效:
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE LOC_ID = 10
UNION
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE REGION = “MELBOURNE”
低效:
SELECT LOC_ID , LOC_DESC , REGION
FROM LOCATION
WHERE LOC_ID = 10 OR REGION = “MELBOURNE”
如果你坚持要用OR, 那就需要返回记录最少的索引列写在最前面.
7. 用EXISTS替代IN、用NOT EXISTS替代NOT IN
在许多基于基础表的查询中, 为了满足一个条件, 往往需要对另一个表进行联接. 在这种情况下, 使用EXISTS(或NOT EXISTS)通常将提高查询的效率.
在子查询中, NOT IN子句将执行一个内部的排序和合并. 无论在哪种情况下, NOT IN都是最低效的(因为它对子查询中的表执行了一个全表遍历).
为了避免使用NOT IN, 我们可以把它改写成外连接(Outer Joins)或NOT EXISTS.
例子：
高效: SELECT * FROM EMP (基础表) WHERE EMPNO 0 AND EXISTS (SELECT ‘X’ FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = ‘MELB’)
低效: SELECT * FROM EMP (基础表) WHERE EMPNO 0 AND DEPTNO IN(SELECT DEPTNO FROM DEPT WHERE LOC = ‘MELB’)