oracle索引

优化器统计范围： 表统计； --行数，块数，行平均长度；all_tables：NUM_ROWS，BLOCKS，AVG_ROW_LEN； 列统计； --列中唯一值的数量（NDV），NULL值的数量，数据分布； --DBA_TAB_COLUMNS：NUM_DISTINCT，NUM_NULLS，HISTOGRAM； 索引统计；--叶块数量，等级，聚簇因子； --DBA_INDEXES：LEAF_BLOCKS，CLUSTERING_FACTOR，BLEVEL； 系统统计；--I/O性能与使用率； --CPU性能与使用率； --存储在aux_stats$中，需要使用dbms_stats收集，I/O统计在X$KCFIO中； ------------- analyze ------------- 需要使用ANALYZE统计的统计： 使用LIST CHAINED ROWS和VALIDATE子句； 收集空闲列表块的统计； Analyze table tablename compute statistics; Analyze index|cluster indexname estimate statistics; ANALYZE TABLE tablename COMPUTE STATISTICS FOR TABLE FOR ALL [LOCAL] INDEXES FOR ALL [INDEXED]

SQL优化 1、介绍 在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是随着互联网大数据的兴起，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。 系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到 上百倍 ，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。 在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引，这有助于写出高性能的SQL语句。我们要做到不但会写SQL,还要做到写出性能优良的SQL,以下是我工作，学习的经验，汇总了部分资料与大家分享！，如发现不合理或错误的地方请大家及时指出来，以便大家共同成长。 2、常见优化规则 2.1 表连接数 连接的表越多，性能越差 可能的话，将连接拆分成若干个过程逐一执行 优先执行可显著减少数据量的连接，既降低了复杂度，也能够容易按照预期执行 如果不可避免多表连接，很可能是设计缺陷 外链接效果差

数据库的优化问题 一、问题的提出 　在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用 系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优 化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的 SQL语句，提高系统的可用性。 　　在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的 SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种 原则来删除索引，这有助于写出高性能的SQL语句。 　二、SQL语句编写注意问题 　　下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。 　　1. IS NULL 与 IS NOT NULL 　　不能用null作索引

如今随着互联网的发展，数据的量级也是撑指数的增长，从GB到TB到PB。对数据的各种操作也是愈加的困难，传统的关系性数据库已经无法满足快速查询与插入数据的需求。这个时候NoSQL的出现暂时解决了这一危机。它通过降低数据的安全性，减少对事务的支持，减少对复杂查询的支持，来获取性能上的提升。但是，在有些场合NoSQL一些折衷是无法满足使用场景的，就比如有些使用场景是绝对要有事务与安全指标的。这个时候NoSQL肯定是无法满足的，所以还是需要使用关系性数据库。 虽然关系型数据库在海量数据中逊色于NoSQL数据库，但是如果你操作正确，它的性能还是会满足你的需求的。针对数据的不同操作，其优化方向也是不尽相同。对于数据移植，查询和插入等操作，可以从不同的方向去考虑。而在优化的时候还需要考虑其他相关操作是否会产生影响。就比如你可以通过创建索引提高查询性能，但是这会导致插入数据的时候因为要建立更新索引导致插入性能降低，你是否可以接受这一降低那。所以，对数据库的优化是要考虑多个方向，寻找一个折衷的最佳方案。 一：查询优化 1：创建索引。 最简单也是最常用的优化就是查询。因为对于CRUD操作，read操作是占据了绝大部分的比例，所以read的性能基本上决定了应用的性能。对于查询性能最常用的就是创建索引。经过测试，2000万条记录，每条记录200字节两列varchar类型的

特别说明： 1、 本文只是面对数据库应用开发的程序员，不适合专业 DBA ， DBA 在数据库性能优化方面需要了解更多的知识； 2、 本文许多示例及概念是基于 Oracle 数据库描述，对于其它关系型数据库也可以参考，但许多观点不适合于 KV 数据库或内存数据库或者是基于 SSD 技术的数据库； 3、 本文未深入数据库优化中最核心的执行计划分析技术。 读者对像： 开发人员： 如果你是做数据库开发，那本文的内容非常适合，因为本文是从程序员的角度来谈数据库性能优化。 架构师： 如果你已经是数据库应用的架构师，那本文的知识你应该清楚 90% ，否则你可能是一个喜欢折腾的架构师。 DBA （数据库管理员）： 大型数据库优化的知识非常复杂，本文只是从程序员的角度来谈性能优化， DBA 除了需要了解这些知识外，还需要深入数据库的内部体系架构来解决问题。 引言 在网上有很多文章介绍数据库优化知识，但是大部份文章只是对某个一个方面进行说明，而对于我们程序员来说这种介绍并不能很好的掌握优化知识，因为很多介绍只是对一些特定的场景优化的，所以反而有时会产生误导或让程序员感觉不明白其中的奥妙而对数据库优化感觉很神秘。 很多程序员总是问如何学习数据库优化，有没有好的教材之类的问题。在书店也看到了许多数据库优化的专业书籍，但是感觉更多是面向 DBA 或者是 PL/SQL 开 发方面的知识

Oracle 索引创建及管理 1. Oracle 索引简介 在 Oracle 数据库中，存储的每一行数据都有一个 rowID 来标识。当 Oracle 中存储着大量的数据时，意味着有大量的 rowID ，此时想要快速定位指定的 rowID ，就需要使用索引对象。 当对 Oracle 表执行指定条件的查询时，常规的方法是将所有的记录取出来，然后再把每一条记录与查询条件作对比，最后返回满足条件的记录。这样操作不仅耗费时间并耗费资源。当有了索引之后，只需要在索引中找到符合查询条件的索引字段值，就可以通过保存在索引中的 rowID 快速找到表中对应的记录。 用户可以根据情况不同创建多种类型的索引。按照索引的存储方式将索引分为 B 树索引、位图索引、反向索引和基于函数的索引。创建索引时需要注意以下几点： l 索引应该建立在 where 子句频繁引用、排序以及分组的列上，如果选择的列不合适将无法提升查询速度； l 限制索引的个数。索引只要提升查询速度，但会降低 DML 操作的速度； l 指定索引块空间的使用参数。基于表建立索引时， Oracle 会将相应表添加到索引块。为索引添加数据时， Oracle 会按照 pctfree 参数在索引块上预留部分空间。如果将来在表上执行大量的 insert 操作，那么应该在建立索引时设置较大的 pctfree ； l 将表和索引部署到相同的表空间

序列： 　　创建默认序列：create sequence 序列名 　　select 序列名.currval from dual；　　显示当前序列值 　　select 序列名.nextval from dual；　　显示下一个序列值 　　开始默认无值，所以创建后第一次不能使用显示当前序列值语句 　　可以动态生成主键值主键位置写序列名.nextval 　　创建自定义序列：create sequence aaa 　　　　　　　　　start with 5　　　--起始位置 　　　　　　　　　increment by 2　　--步长 　　　　　　　　　maxvalue 1000　　--最大值为1000 　　　　　　　　　cache 10　　--缓存10 　　删除序列 ：drop sequence 序列名　　 索引（显式创建，隐式执行）： 　　提升查询速率（数据量大的时候） 　　创建索引 create index 索引名 on 表名（字段名） 　　Oracle 会默认给主键创建索引 　　删除索引：drop index 索引名 视图（dba权限才能创建）： 　　创建视图：create view 视图名 as 查询语句 　　删除视图：drop view 视图名 　　可以隐藏真实表，保护核心数据 　　在视图中的执行会映射到真实表中 　　创建只读视图：create view 视图名 as 查询语句

MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC ( Multi-Version Concurrency Control ) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。 在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。当前读，读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。 Innodb锁问题 InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。行级锁与表级锁本来就有许多不同之处，另外，事务的引入也带来了一些新问题。下面我们先介绍一点背景知识，然后详细讨论InnoDB的锁问题。 InnoDB实现了以下两种类型的行锁。 l 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。

一、为什么用自增列作为主键？ 　　1、如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引。 　　如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引。 　　如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。 　　2、数据记录本身被存于主索引（一颗B+Tree）的叶子节点上，这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放 　　因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子（InnoDB默认为15/16），则开辟一个新的页（节点） 　　3、如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页 　　4、如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置 　　此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销 　　同时频繁的移动、分页操作造成了大量的碎片

1 查询操作 2 1、查询所有记录 3 db.userInfo.find(); 4 相当于: 5 select* from userInfo; 6 7 2、查询去掉后的当前聚集集合中的某列的重复数据 8 db.userInfo.distinct("name"); 9 会过滤掉name中的相同数据 10 相当于： 11 select disttince name from userInfo; 12 13 3、查询age = 22的记录 14 db.userInfo.find({"age": 22}); 15 相当于： 16 select * from userInfo where age = 22; 17 18 4、查询age > 22的记录 19 db.userInfo.find({age: {$gt: 22}}); 20 相当于： 21 select * from userInfo where age >22; 22 23 5、查询age < 22的记录 24 select * from userInfo where age <22; 25 26 6、查询age >= 25的记录 27 db.userInfo.find({age: {$gte: 25}}); 28 相当于: 29 select * from userInfo where age >= 25; 30 31 7