oracle索引

1.什么是B-Tree 和 B+Tree，他们是做什么用的？ B-Tree是为了磁盘或其它存储设备而设计的一种 多叉平衡查找树 ，B-Tree 和 B+Tree 广泛应用于文件存储系统以及 数据库 系统中。 在大规模数据存储中，实现索引查询这样一个实际背景下，树节点存储的元素数量是有限的（如果元素数量非常多的话，树的高度就会增大，查找就退化成节点内部的线性查找了），这样导致二叉查找树结构由于 树的深度过大而造成磁盘I/O读写过于频繁，进而导致查询效率低下 （为什么会出现这种情况？这跟外部存储器-磁盘的存储方式有关）。那么该如何减少树的高度呢？一个基本的想法就是：采用 多叉树 结构（每个节点存放多个元素，每个节点有多个子节点，这样树的高度就降低了）。根据平衡二叉树的启发，自然就想到平衡多路查找树结构。B-Tree的各种操作能使B-Tree保持较低的高度，从而达到有效避免磁盘过于频繁的查找存取操作，从而有效提高查找效率。 2.B-Tree 2.1定义 m阶B-Tree满足以下条件： 1、每个节点最多拥有m个子树 2、根节点至少有2个子树 3、分支节点至少拥有m/2颗子树（除根节点和叶子节点外都是分支节点） 4、所有叶子节点都在同一层 5、每个节点最多可以有m-1个key 6、每个节点中的key以升序排列 7、节点中key元素左节点的所有值都小于或等于该元素

硬件 索引 碎片 SQL逻辑 扩展分区 数据库负载 硬件 CPU速度、内存大小、磁盘读写速度、网络传输速度 索引 是否走索引，索引是否合理 碎片 表碎片和索引碎片，可能导致使用错误的执行计划 SQL逻辑 SQL本身逻辑有问题，执行效率低 扩展分区 表和索引初始化参数配置不同，导致扩展分区大小不一，影响查询速度 数据库负载 数据库负载过重 来源： CSDN 作者： Angryshark_128 链接： https://blog.csdn.net/weixin_42078760/article/details/104079582

1.什么是B-Tree 和 B+Tree，他们是做什么用的？ B-Tree是为了磁盘或其它存储设备而设计的一种 多叉平衡查找树 ，B-Tree 和 B+Tree 广泛应用于文件存储系统以及数据库系统中。 在大规模数据存储中，实现索引查询这样一个实际背景下，树节点存储的元素数量是有限的（如果元素数量非常多的话，树的高度就会增大，查找就退化成节点内部的线性查找了），这样导致二叉查找树结构由于 树的深度过大而造成磁盘I/O读写过于频繁，进而导致查询效率低下 （为什么会出现这种情况？这跟外部存储器-磁盘的存储方式有关）。那么该如何减少树的高度呢？一个基本的想法就是：采用 多叉树 结构（每个节点存放多个元素，每个节点有多个子节点，这样树的高度就降低了）。根据平衡二叉树的启发，自然就想到平衡多路查找树结构。B-Tree的各种操作能使B-Tree保持较低的高度，从而达到有效避免磁盘过于频繁的查找存取操作，从而有效提高查找效率。 2.B-Tree 2.1定义 m阶B-Tree满足以下条件： 1、每个节点最多拥有m个子树 2、根节点至少有2个子树 3、分支节点至少拥有m/2颗子树（除根节点和叶子节点外都是分支节点） 4、所有叶子节点都在同一层 5、每个节点最多可以有m-1个key 6、每个节点中的key以升序排列 7、节点中key元素左节点的所有值都小于或等于该元素

1.什么是B-Tree 和 B+Tree，他们是做什么用的？ B-Tree是为了磁盘或其它存储设备而设计的一种 多叉平衡查找树 ，B-Tree 和 B+Tree 广泛应用于文件存储系统以及数据库系统中。 在大规模数据存储中，实现索引查询这样一个实际背景下，树节点存储的元素数量是有限的（如果元素数量非常多的话，树的高度就会增大，查找就退化成节点内部的线性查找了），这样导致二叉查找树结构由于 树的深度过大而造成磁盘I/O读写过于频繁，进而导致查询效率低下 （为什么会出现这种情况？这跟外部存储器-磁盘的存储方式有关）。那么该如何减少树的高度呢？一个基本的想法就是：采用 多叉树 结构（每个节点存放多个元素，每个节点有多个子节点，这样树的高度就降低了）。根据平衡二叉树的启发，自然就想到平衡多路查找树结构。B-Tree的各种操作能使B-Tree保持较低的高度，从而达到有效避免磁盘过于频繁的查找存取操作，从而有效提高查找效率。 2.B-Tree 2.1定义 m阶B-Tree满足以下条件： 1、每个节点最多拥有m个子树 2、根节点至少有2个子树 3、分支节点至少拥有m/2颗子树（除根节点和叶子节点外都是分支节点） 4、所有叶子节点都在同一层 5、每个节点最多可以有m-1个key 6、每个节点中的key以升序排列 7、节点中key元素左节点的所有值都小于或等于该元素

什么是索引 索引是数据库对象之一，合理的使用索引可以大大降低 i/o 次数用于加快数据的检索，类似于书籍的索引。在数据库中索引可以减少数据库程序查询结果时需要读取的数据量，类似于在书籍中我们利用索引可以不用翻阅整本书即可找到想要的信息。 索引是建立在表上的可选对象；索引的关键在于通过一组排序后的索引键来取代默认的全表扫描检索方式，从而提高检索效率 索引在逻辑上和物理上都与相关的表和数据无关，当创建或者删除一个索引时，不会影响基本的表； 索引一旦建立，在表上进行 DML 操作时（例如在执行插入、修改或者删除相关操作时），oracle 会自动管理索引，索引删除，不会对表产生影响 索引对用户是透明的，无论表上是否有索引，sql 语句的用法不变 oracle 创建主键时会自动在该列上创建索引 但是在对表进行DML操作，也就是删除，新增，修改时，由于要表的存放位置记录到索引项中 而会降低一些速度。 注意 ： 1.一个基表不能建太多的索引； 2.空值不能被索引 3.只有唯一索引才真正提高速度,一般的索引只能提高 30%左右。 建立索引 CREATE [UNIQUE] | [BITMAP] INDEX index_name --unique 表示唯一索引 ON table_name([column1 [ASC|DESC],column2 --bitmap，创建位图索引 [ASC|DESC],…]

oracle数据库的整体结构 数据库的结构关系 　　其实，我前面一篇讲表空间的时候就介绍了数据库的结构，只是那个图只是简单的层次关系，这张图片看上去挺封复杂的，只要关注几个概念就行了。 Database （数据库） ：数据库是按照数据结构来组织、存储和管理数据的仓库。 Tablespaces （表空间） ：表空间是数据库的逻辑划分，一个表空间只能属于一个数据库。所有的数据库对象都存放在指定的表空间中。但主要存放的对象是表， 所以称作表空间。 Segments （段） ： 段是表空间的重要组织结构，段是指占用数据文件空间的通称，或数据库对象使用的空间的集合；段可以有表段、索引段、回滚段、临时段和高速缓存段等。 extents （盘区） ：是数据库存储空间分配的一个逻辑单位，它由连续数据块所组成。第一个段是由一个或多个盘区组成。当一段中间所有空间已完全使用，oracle 为该段分配一个新的范围。 Data Block （数据块） ： 是 oralce 管理数据文件中存储空间的单位，为数据库使用的 I/O 的最小单位，其大小可不同于操作系统的标准 I/O 块大小。 （ Storage Clause Precedence ）存储规范优先 　　Oracle 在存储控制上可以分为三个方式。 oracle 缺省级别、表空间级别、段级别，可以理解中央、省级、县级。从中央到地方的法规条例

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

参考了这篇文章： http://www.cnblogs.com/LBSer/p/5183300.html 《 mysql死锁问题分析 》 写的不错。 如果Mysql死锁，会报出： 1.1 死锁成因&&检测方法 我们mysql用的存储引擎是innodb，从日志来看，innodb主动探知到死锁，并回滚了某一苦苦等待的事务。问题来了，innodb是怎么探知死锁的？ 直观方法是在两个事务相互等待时，当一个等待时间超过设置的某一阀值时，对其中一个事务进行回滚，另一个事务就能继续执行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。 仅用上述方法来检测死锁太过被动，innodb还提供了 wait-for graph算法 来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。 1.2 innodb隔离级别、索引与锁 1.2.1 锁与索引的关系 假设我们有一张消息表（msg），里面有3个字段。假设id是主键，token是非唯一索引，message没有索引。 id: bigint token: varchar(30) message: varchar(4096) innodb对于主键使用了 聚簇索引 ，这是一种数据存储方式，表数据是和主键一起存储，主键索引的叶结点存储行数据。对于普通索引

5.1 InnoDB存储引擎索引概述 183 InnoDB存储引擎支持以下几种常见的索引: B+树索引 全文索引 哈希索引 InnoDB 存储引擎支持的哈希索引是自适应的，InnoDB 存储引擎会根据表的使用情况自动为表生成哈希索引，不能人为干预是否在一张表中生成哈希索引。 B+树索引目前关系型数据库系统中查找最为常用和最为有效的索引。 B+树索引并不能找到一个给定键值的具体行，只能找到对应的页，然后把页读到内存，再在内存中进行查找。 5.2 数据结构与算法 184 5.2.1 二分查找法 184 5.2.2 二叉查找树和平衡二叉树 185 5.3 B+树 187 5.3.1 B+树的插入操作 187 5.3.2 B+树的删除操作 190 5.4 B+树索引 191 根据叶子节点存放的是否是一整行的信息，可将数据库中的B+树索引分为聚集索引(clustered inex)和辅助索引（非聚集索引）(secondary index) 5.4.1 聚集索引 192 聚集索引(clustered index)就是按照每张表的主键构造一棵 B+树，同时叶子节点中存放的即为表的行记录数据（所有叶子节点加起来就是整张表的行记录数据），也将聚集索引的叶子节点称为数据页。 聚集索引的存储并不是物理上连续的，而是逻辑上连续的。 5.4.2 辅助索引 196 对于辅助索引(Secondary Index

一:SQL性能优化原理 1.1sql处理体系结构 1.2执行计划 sql语句转换前的步骤: 1.语法检查:检查sql语句的拼写是否正确 2.语义分析:核实所有与数据字典不一致的表或列的名字 3.概要存储检查:检查数据字典,以确定该sql语句的概要信息是否已经存在 4.生产执行计划:使用CBO规则和数据字典中的统计表来决定最佳执行计划 5.生成二进制代码:基于执行计划,生成可执行代码 执行计划是oracle在执行每个sql语句时所采取的执行顺序. 执行计划包括: 1.语句所引用的表的顺序 2.语句所设计的表的访问方式 3.语句中连续操作所影响到的各表的连接方法 查看计划前授权: --系统用户执行 SQL > @D :\Oracle\app\oracle\product\ 10.2 .0 \server\RDBMS\ADMIN\utlxplan . sql ; --本地电脑路径,执行utlxplan.sql Table created Executed in 0.047 seconds SQL > grant plustrace to scott ; --授权 Grant succeeded Executed in 0.009 seconds --scott用户 SQL > @D :\Oracle\app\oracle\product\ 10.2 .0 \server\RDBMS