声明:虽然题目是Oracle.但同样适合MySQL InnoDB索引          在大多数情况下.复合索引比单字段索引好     很多系统就是靠新建一些合适的复合索引.使效率大幅度提高     复合索引比单字段索引复杂.有两个原则需把握:前缀性和可选性     但是.可叹的是.国内很多IT系统开发人员没有意识到应该优先设计复合索引     更没有充分理解复合索引的前缀性和可选性这两个重要原则          ㈠ 前缀性(Prefixing)                  在谓词条件中

清除oralce 缓存:alter system flush buffer_cache; 环境:oracle 10g . 400万条数据,频率5分钟一条 1.应用场景:  找出所有站点的最新一条数据.sql语句如下: —————————————————————————————————————————————————— with aa as( select t1.EQP_ID ,max(MEASURE_TIME) maxtm from PLU_WATER_DATA t1 where t1.MEAS

前缀性: 复合索引的前缀性是指只有当复合索引的第一个字段出现在SQL语句的谓词条件中时,该索引才会被用到.如复合索引为(ename,job,mgr),只要谓词条件中出现第一个字段ename,就可以用复合索引,否则不会用.唯一的例外是skip scan index,就是如果Oracle发现第一个字段的值很少,会自动拆分为两个复合索引.如复合索引(gender,ename,job,mgr),因为第一个字段gender只有两个值:男和女,因此Oracle会将这个索引拆分成('男',ename,job,

本文出处:http://www.cnblogs.com/wy123/p/6008477.html 关于统计信息对数据行数做预估,之前写过对非相关列(单独或者单独的索引列)进行预估时候的算法,参考这里. 今天来写一下统计信息对于复合索引在预估时候的计算方法和潜在问题. 本文原形来自于是个实际业务问题,某SQL在利用一个符合索引做查询的时候,发现始终会出现预估误差较大的情况, 而改变复合索引的列顺序,这个预估行数的误差会发生变化, 也就是说,Create index idx_index1 ON Ta

说说复合索引 写索引的博客太多了,一直不想动手写,有一下两个原因:一是觉得有炒剩饭的嫌疑,有兄弟曾说:索引吗,只要在查询条件上建索引就行了,真的可以这么暴力吗?二来觉得,索引是个非常大的话题,很难概括出所有的情况,你不整出点新意来,倒是有抄袭照搬的嫌疑 既然写了,就写一点稍微不一样的东西出来,好了,废话打住,开搞 搭建测试环境: 创建一张表,模拟实际业务中的一个表,往里面填入数据,时间字段上,相对按照时间均匀地填充,其他字段以GUID填充 Create table BusinessInfoTab

对于复合索引:Mysql从左到右的使用索引中的字段,一个查询可以只使用索引中的一部份,但只能是最左侧部分.例如索引是key index (a,b,c). 可以支持a | a,b| a,b,c 3种组合进行查找,但不支持 b,c进行查找 .当最左侧字段是常量引用时,索引就十分有效.下面用几个例子对比查询条件的不同对性能影响. create table test(a int,b int,c int,KEY a(a,b,c)); 优: select * from test where a=10 and

          索引这块从存储结构来分,有2大类,聚集索引和非聚集索引,而非聚集索引在堆表或者在聚集索引表都会对其 键值有所影响,这块可以详细查看本系列第二篇文章:SQL SERVER大话存储结构_(2)_非聚集索引如何查找到行记录.     非聚集索引内又分为多类:单列索引.复合索引.包含索引.过滤索引等.之前文章有具体分析过非聚集索引的存储情况,但是没有对复合索引及包含索引做过多说明,本文来讲讲这两个索引.         如果转载,请注明博文来源: www.cnblogs.com/xi

一. 1.索引越少越好,在修改数据时,第个索引都要进行更新,降低写速度.2.最窄的字段放在键的左边3.避免file sort排序,临时表和表扫描. 二.复合索引的建立原则: 如果您很可能仅对一个列多次执行搜索,则该列应该是复合索引中的第一列.如果您很可能对一个两列索引中的两个列执行单独的搜索,则应该创建另一个仅包含第二列的索引.如上图所示,如果查询中需要对年龄和性别做查询,则应当再新建一个包含年龄和性别的复合索引.包含多个列的主键始终会自动以复合索引的形式创建索引,其列的顺序是它们在表定义中出现

复合索引(又称为联合索引),是在多个列上创建的索引.创建复合索引最重要的是列顺序的选择,这关系到索引能否使用上,或者影响多少个谓词条件能使用上索引.复合索引的使用遵循最左匹配原则,只有索引左边的列匹配到,后面的列才能继续匹配.本文主要探究复合索引的创建顺序与使用情况. (一)复合索引的概念 在单个列上创建的索引我们称为单列索引,在2个以上的列上创建的索引称为复合索引.在单个列上创建索引相对简单,通常只需要考虑列的选择率即可,选择性越好,代表数据越分散,创建出来的索引性能也就更好.通常,某列选择率

好久不碰数据库底层细节的东西,前几天,一个小家伙跑来找我,非要说复合b*tree index branch block中只包含先导列键值信息,并不包含非先导列键值信息,而且还dump了branch block,用以证明他的说法,从常理和SQL的语句执行信息就可以知道,他的说法是有问题的,但如何证明这一点呢?为了证明这点,也麻烦一次,玩玩多年不碰的dump.下面是他证明自己观点的两个dump结果(一个为单键索引,另一个是复合索引): 下面是本人的测试过程和结果: create table t1(c

1. 理解ROWID ROWID是由Oracle自动加在表中每行最后的一列伪列,既然是伪列,就说明表中并不会物理存储ROWID的值:你可以像使用其它列一样使用它,只是不能对该列的值进行增.删.改操作:一旦一行数据插入后,则其对应的ROWID在该行的生命周期内是唯一的,即使发生行迁移,该行的ROWID值也不变.SELECT t.rowid,t.* FROM DM_COMM_PREM_LIST t where LIST_ID= '3106355531'; 2. SQL优化器优化方式1)基于规则的优化

摘要:今天为什么提到这个话题,出于一个偶然,一个同事在优化新开发的系统时向我请教如何添加复合压缩索引的问题.我总结了一下,问题有三. 第一:需不需要压缩 第二:对第几列压缩 第三:性能对比,选出最优 好,问题提出我们一一来解答一下 1.场景 在我的文章中经常会看到这个词,当然也可以不谈场景说技术,但我觉的那只是隔空建楼,毫无目的,没有根据性.我们在深入研究的时候要避免这样的盲目讨论,效果也不会好太多.注重技术的应用场景,才是研究技术.应用技术之根本,不管多么高科技的东东,或者说多牛的技术,最终还

数据库索引: 索引有单列索引,复合索引之说,如果某表的某个字段有主键约束和唯一性约束,则Oracle 则会自动在相应的约束列上建议唯一索引.数据库索引主要进行提高访问速度. 建设原则: 1.索引应该经常建在where 子句经常用到的列上.如果某个大表经常使用某个字段进行查询,并且检索行数小于总表行数的5%.则应该考虑. 2.对于两表连接的字段,应该建立索引.如果经常在某表的一个字段进行order By 则也经过进行索引. 3.不应该在小表上建设索引. 优缺点: 1.索引主要进行提高数据的查询速度

一.索引分类      按逻辑分: 单列索引(Single column):  单列索引是基于单列所创建的索引 复合(多列)索引(Concatenated ): 复合索引是基于两列或者多列所创建的索引  唯一索引(Unique ): 唯一索引是索引列值不能重复的索引. 非唯一索引(NonUnique ): 非唯一索引是索引列可以重复的索引.  函数索引(Function-based): Oracle中不仅能够直接对表中的列创建索引,还可以对包含列的函数或表达式创建索引,这种索引称为“位图索引”.

一.索引简介 1.索引相当于目录 2.索引是通过一组排序后的索引键来取代默认的全表扫描检索方式,从而提高检索效率. 3.索引的创建要适度,多了会影响增删改的效率,少了会影响查询的效率,索引最好创建在取值分散的列上,避免对同一张表创建过多的索引 4.索引的使用对用户来说是透明的,由系统来决定什么时候使用索引. 5.Oracle支持多种类型的索引,可以按列的多少.索引值是否唯一和索引数据的组织形式对索引进行分类,以满足各种表和查询条件的要求.(请见附件) a. 单列索引和复合索引     b．B树索

原文引至:http://jvortex.blog.163.com/blog/static/16961890020122141010878/ 我们知道,索引是用于加速数据库查询的数据库对象.原理就是减少查询的IO操作,从而达到加速的目的.本文我们主要对SQL Server,Oracle,DB2上的索引建立语句进行了总结,接下来就让我们一起来了解一下这部分内容. 索引的种类: 聚集索引:根据数据行的键值在表或视图中排序和存储这些数据行. 非聚集索引:具有独立于数据行的结构. 唯一索引:确保索引键不包

容易引起oracle索引失效的原因很多: 1.在索引列上使用函数.如SUBSTR,DECODE,INSTR等,对索引列进行运算.需要建立函数索引就可以解决了. 2.新建的表还没来得及生成统计信息,分析一下就好了 3.基于cost的成本分析,访问的表过小,使用全表扫描的消耗小于使用索引. 4.使用<>.not in .not exist,对于这三种情况大多数情况下认为结果集很大,一般大于5%-15%就不走索引而走FTS. 5.单独的>.<. 6.like "%_"

简介 1.说明 1)索引是数据库对象之一,用于加快数据的检索,类似于书籍的目录.在数据库中索引可以减少数据库程序查询结果时需要读取的数据量,类似于在书籍中我们利用目录可以不用翻阅整本书即可找到想要的信息. 2)索引是建立在表上的可选对象:索引的关键在于通过一组排序后的索引键来取代默认的全表扫描检索方式,从而提高检索效率. 3)索引在逻辑上和物理上都与相关的表和数据无关,当创建或者删除一个索引时,不会影响基本的表: 4)索引一旦建立,在表上进行DML操作时(例如在执行插入.修改或者删除操作时),o

索引建立原则 确定针对该表的操作是大量的查询操作还是大量的增删改操作. 尝试建立索引来帮助特定的查询.检查自己的sql语句,为那些频繁在where子句中出现的字段建立索引. where语句中不得不对查询列采用函数查询,如upper函数,最好建立相应函数索引: 在SQL语句中经常进行GROUP BY.ORDER BY的字段上建立索引 用于联接的列(主健/外健)上建立索引: 在经常存取的多个列上建立复合索引,但要注意复合索引的建立顺序要按照使用的频度来确定: 尝试建立复合索引来进一步提高系统性能.修

索引无效原因 最近遇到一个SQL语句的性能问题,修改功能之前的运行时间平均为0.3s,可是添加新功能后,时间达到了4~5s.虽然几张表的数据量都比较大(都在百万级以上),但是也都有正确创建索引,不知道到底慢在了哪里,下面展开调查. 经过几次排除,把问题范围缩小在索引上,首先在确定索引本身没有问题的前提下,考虑索引有没有被使用到,那么新的问题来了,怎么知道指定索引是否被启用. 判断索引是否被执行 1. 分析索引 即将索引至于监控状态下,对索引进行分析.如下对ID_TT_SHOHOU_HIST_00